From jhaas@slice.pfrc.org Mon Jul 11 10:14:45 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0990011E80EB for ; Mon, 11 Jul 2011 10:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vulYeJcboXDX for ; Mon, 11 Jul 2011 10:14:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5423311E8100 for ; Mon, 11 Jul 2011 10:14:40 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 72E892240BE; Mon, 11 Jul 2011 17:19:05 +0000 (UTC) Date: Mon, 11 Jul 2011 17:19:05 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Time for a recharter Message-ID: <20110711171905.GS30842@slice> References: <20110507133545.GB17459@slice> <20110606010010.GH6269@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110606010010.GH6269@slice> User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2011 17:14:45 -0000 Working Group, Since there has been no further comment on the charter, we will be contacting the respective draft authors for charter items over the next few days to help set milestones. Once the milestones have been collected, we will submit the charter for approval. Again, one item of interest that is not on the current charter is the recently posted interest for BFD over LAG/ECMP. We'd like to encourage the working group to continue discssion on this topic and submit I-Ds with proposed solutions. -- Jeff From jhaas@slice.pfrc.org Wed Jul 27 11:39:42 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777321F8B73; Wed, 27 Jul 2011 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+ttiksgYGRI; Wed, 27 Jul 2011 11:39:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 284D221F8B6B; Wed, 27 Jul 2011 11:39:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EBC762240C9; Wed, 27 Jul 2011 18:45:00 +0000 (UTC) Date: Wed, 27 Jul 2011 18:45:00 +0000 From: Jeffrey Haas To: karp@ietf.org, rtg-bfd@ietf.org Subject: BFD authentication documents of interest to KARP Message-ID: <20110727184500.GA3056@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2011 18:39:42 -0000 As per the IETF 81 KARP session, Manav has a document that is intended to address some of the security gap issues for BFD: http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 This document should be adopted as a WG item in BFD once our charter clears IESG. Please note that the authors were requested to split the document into two components: 1. The SHA-2 procedures 2. The generic keying mechanism. Please examine these documents for coverage of issues found in the KARP reviews. If there are additional gaps, consider if they are appropriate to include in the above documents or require a new document in BFD. -- Jeff (speaking as chair) From vishwas.ietf@gmail.com Wed Jul 27 12:35:39 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F250811E8075; Wed, 27 Jul 2011 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTBzHuiFUbD1; Wed, 27 Jul 2011 12:35:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0807C11E8084; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) Received: by vxi40 with SMTP id 40so1776007vxi.31 for ; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WU+MDwJIYKhD+YCqDZgFLzd/+9Km7yZg5oblJZEYnJE=; b=AYVI59NRW/cCHI7BZrF1gU/btTJgQjIvkTCTlUK1r74KxtnM20Itfz3kyKp2Rshb7g aMu9jH+zu88n5G2YtL6N3ZCq2DlfQhbcF5bz6kftObwqTn1o/t4D5xTFX5zkDSL79rp2 Qa+Ar42sLViyfu84EG3qg98ymZEy3byWAbrG8= MIME-Version: 1.0 Received: by 10.52.185.40 with SMTP id ez8mr244022vdc.112.1311795336387; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) Received: by 10.52.158.234 with HTTP; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) In-Reply-To: <-1579726451630081949@unknownmsgid> References: <20110727184500.GA3056@slice> <-1579726451630081949@unknownmsgid> Date: Wed, 27 Jul 2011 12:35:36 -0700 Message-ID: Subject: Re: [karp] BFD authentication documents of interest to KARP From: Vishwas Manral To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=bcaec547c61d0b1c6c04a912272b Cc: "rtg-bfd@ietf.org" , "karp@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2011 19:35:39 -0000 --bcaec547c61d0b1c6c04a912272b Content-Type: text/plain; charset=ISO-8859-1 Hi Mahesh, BFD does not only run on UDP, look at the work for BFD for MPLS-TP networks. One of the advantages of BFD is that protocol packets do not contain any transport specific information.:) With that said I agree if there was a mechanism to secure messages over UDP, that would be better then do the same for every protocol over UDP. Thanks, Vishwas On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > I see a general need for key management for all routing/signaling > protocols that are either connection oriented or connectionless. Would > it make sense to combine efforts? I know that Vero presented a LDP > Hello draft today that is based on UDP. Could that be extended to > cover all of UDP based protocols and BFD? > > On Jul 27, 2011, at 11:39 AM, Jeffrey Haas wrote: > > > As per the IETF 81 KARP session, Manav has a document that is intended to > address > > some of the security gap issues for BFD: > > > > http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 > > > > This document should be adopted as a WG item in BFD once our charter > clears > > IESG. Please note that the authors were requested to split the document > > into two components: > > 1. The SHA-2 procedures > > 2. The generic keying mechanism. > > > > Please examine these documents for coverage of issues found in the KARP > > reviews. If there are additional gaps, consider if they are appropriate > to > > include in the above documents or require a new document in BFD. > > > > -- Jeff (speaking as chair) > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > --bcaec547c61d0b1c6c04a912272b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mahesh,
=A0
BFD does not only run on UDP, look at the work for BFD for MPLS-TP net= works. One of the advantages of BFD is that protocol packets do not contain= any transport specific information.:)
=A0
With that said I agree if there was a mechanism to secure messages ove= r UDP, that would be better then do the same for every protocol over UDP.
=A0
Thanks,
Vishwas
On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethana= ndani <mjet= hanandani@gmail.com> wrote:
I see a general need for key man= agement for all routing/signaling
protocols that are either connection o= riented or connectionless. Would
it make sense to combine efforts? I know that Vero presented a LDP
Hello= draft today that is based on UDP. Could that be extended to
cover all o= f UDP based protocols and BFD?

On Jul 27, 2011, at 11:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> As pe= r the IETF 81 KARP session, Manav has a document that is intended to addres= s
> some of the security gap issues for BFD:
>
> http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03
>
> This document should be adopted as a WG item in BFD once our charter c= lears
> IESG. =A0Please note that the authors were requested to split= the document
> into two components:
> 1. The SHA-2 procedures<= br> > 2. The generic keying mechanism.
>
> Please examine these = documents for coverage of issues found in the KARP
> reviews. =A0If t= here are additional gaps, consider if they are appropriate to
> inclu= de in the above documents or require a new document in BFD.
>
> -- Jeff (speaking as chair)
> __________________________= _____________________
> karp mailing list
> karp@ietf.org
> https://www.ietf.org/mailman/listinfo= /karp
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailm= an/listinfo/karp

--bcaec547c61d0b1c6c04a912272b-- From tnadeau@lucidvision.com Wed Jul 27 12:46:28 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578EC11E812F; Wed, 27 Jul 2011 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYiKl5WKRENe; Wed, 27 Jul 2011 12:46:27 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7B35811E8114; Wed, 27 Jul 2011 12:46:27 -0700 (PDT) Received: from [130.129.19.44] (dhcp-132c.meeting.ietf.org [130.129.19.44]) by lucidvision.com (Postfix) with ESMTP id 047C71D2D2CF; Wed, 27 Jul 2011 15:46:27 -0400 (EDT) References: <20110727184500.GA3056@slice> <-1579726451630081949@unknownmsgid> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-19-628845124 Message-Id: <8C43BB8E-5428-4A63-9207-0FB362373CDD@lucidvision.com> X-Mailer: iPad Mail (8J2) From: Thomas Nadeau Subject: Re: [karp] BFD authentication documents of interest to KARP Date: Wed, 27 Jul 2011 15:46:49 -0400 To: Vishwas Manral Cc: Mahesh Jethanandani , "rtg-bfd@ietf.org" , "karp@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2011 19:46:28 -0000 --Apple-Mail-19-628845124 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii BFD also runs inside of pseudo wires ala VCCV and natively inside of MPLS, s= o I think you have your work cutout if you want to go down this path. Tom On Jul 27, 2011, at 3:35 PM, Vishwas Manral wrote: > Hi Mahesh, > =20 > BFD does not only run on UDP, look at the work for BFD for MPLS-TP network= s. One of the advantages of BFD is that protocol packets do not contain any t= ransport specific information.:) > =20 > With that said I agree if there was a mechanism to secure messages over UD= P, that would be better then do the same for every protocol over UDP. > =20 > Thanks, > Vishwas > On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethanandani wrote: > I see a general need for key management for all routing/signaling > protocols that are either connection oriented or connectionless. Would > it make sense to combine efforts? I know that Vero presented a LDP > Hello draft today that is based on UDP. Could that be extended to > cover all of UDP based protocols and BFD? >=20 > On Jul 27, 2011, at 11:39 AM, Jeffrey Haas wrote: >=20 > > As per the IETF 81 KARP session, Manav has a document that is intended t= o address > > some of the security gap issues for BFD: > > > > http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 > > > > This document should be adopted as a WG item in BFD once our charter cle= ars > > IESG. Please note that the authors were requested to split the document= > > into two components: > > 1. The SHA-2 procedures > > 2. The generic keying mechanism. > > > > Please examine these documents for coverage of issues found in the KARP > > reviews. If there are additional gaps, consider if they are appropriate= to > > include in the above documents or require a new document in BFD. > > > > -- Jeff (speaking as chair) > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp >=20 --Apple-Mail-19-628845124 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
BFD also runs inside of pseudo wires ala VCCV and natively inside of MPLS, so I think you have your work cutout if you want to go down this path.

Tom



On Jul 27, 2011, at 3:35 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:

Hi Mahesh,
 
BFD does not only run on UDP, look at the work for BFD for MPLS-TP networks. One of the advantages of BFD is that protocol packets do not contain any transport specific information.:)
 
With that said I agree if there was a mechanism to secure messages over UDP, that would be better then do the same for every protocol over UDP.
 
Thanks,
Vishwas
On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
I see a general need for key management for all routing/signaling
protocols that are either connection oriented or connectionless. Would
it make sense to combine efforts? I know that Vero presented a LDP
Hello draft today that is based on UDP. Could that be extended to
cover all of UDP based protocols and BFD?

On Jul 27, 2011, at 11:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> As per the IETF 81 KARP session, Manav has a document that is intended to address
> some of the security gap issues for BFD:
>
> http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03
>
> This document should be adopted as a WG item in BFD once our charter clears
> IESG.  Please note that the authors were requested to split the document
> into two components:
> 1. The SHA-2 procedures
> 2. The generic keying mechanism.
>
> Please examine these documents for coverage of issues found in the KARP
> reviews.  If there are additional gaps, consider if they are appropriate to
> include in the above documents or require a new document in BFD.
>
> -- Jeff (speaking as chair)
> _______________________________________________
> karp mailing list
> karp@ietf.org
> https://www.ietf.org/mailman/listinfo/karp
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

--Apple-Mail-19-628845124-- From mjethanandani@gmail.com Wed Jul 27 11:56:28 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39611E80AD; Wed, 27 Jul 2011 11:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJOWKkNFsPZF; Wed, 27 Jul 2011 11:56:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43A1521F8733; Wed, 27 Jul 2011 11:56:27 -0700 (PDT) Received: by wyj26 with SMTP id 26so1203945wyj.31 for ; Wed, 27 Jul 2011 11:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=yrj4dUE2Ql5VWw1gn5hcGzkF+odZ0yfzcckHpWMwohY=; b=qmryM2GNMPds6gTKgaG9MN2cNS9xK5LlJ/cdbbokCS4RZE1CsFMSARaS22k6Db0Ycc kGdQiJbp9dMnpTZT/S1HFqiDWH5rGrvL5+8wqd8tGBQUVZ4kw78HicGOjZ48BHrNkreY 26eMFGiPNLdOVU0dwcbntWBnrKV6y5ysjji2o= Received: by 10.217.3.17 with SMTP id q17mr37093wes.107.1311792983943; Wed, 27 Jul 2011 11:56:23 -0700 (PDT) References: <20110727184500.GA3056@slice> From: Mahesh Jethanandani In-Reply-To: <20110727184500.GA3056@slice> Mime-Version: 1.0 (iPhone Mail 8G4) Date: Wed, 27 Jul 2011 11:56:15 -0700 Message-ID: <-1579726451630081949@unknownmsgid> Subject: Re: [karp] BFD authentication documents of interest to KARP To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 28 Jul 2011 08:20:52 -0700 Cc: "rtg-bfd@ietf.org" , "karp@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2011 18:56:28 -0000 I see a general need for key management for all routing/signaling protocols that are either connection oriented or connectionless. Would it make sense to combine efforts? I know that Vero presented a LDP Hello draft today that is based on UDP. Could that be extended to cover all of UDP based protocols and BFD? On Jul 27, 2011, at 11:39 AM, Jeffrey Haas wrote: > As per the IETF 81 KARP session, Manav has a document that is intended to address > some of the security gap issues for BFD: > > http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 > > This document should be adopted as a WG item in BFD once our charter clears > IESG. Please note that the authors were requested to split the document > into two components: > 1. The SHA-2 procedures > 2. The generic keying mechanism. > > Please examine these documents for coverage of issues found in the KARP > reviews. If there are additional gaps, consider if they are appropriate to > include in the above documents or require a new document in BFD. > > -- Jeff (speaking as chair) > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From mach.chen@huawei.com Thu Jul 28 15:34:57 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79E11E80B6 for ; Thu, 28 Jul 2011 15:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKm4K-adasvZ for ; Thu, 28 Jul 2011 15:34:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B030B11E80AF for ; Thu, 28 Jul 2011 15:34:56 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200JQZEQ6J7@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Fri, 29 Jul 2011 06:34:55 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200MDKEQ697@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Fri, 29 Jul 2011 06:34:54 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR47416; Fri, 29 Jul 2011 06:34:54 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 06:34:46 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 06:34:54 +0800 Date: Thu, 28 Jul 2011 22:34:53 +0000 From: Mach Chen Subject: Solicit comments on BFD for Interface draft X-Originating-IP: [172.24.2.40] To: "rtg-bfd@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMTXaSGUO8YfsvQESe7fRUbEFViw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jul 2011 22:34:57 -0000 Hi, We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD running over interface(e.g., LAG/Bundle interface). You are very welcome to read the draft and give your comments. Many thanks, Mach From manav.bhatia@alcatel-lucent.com Thu Jul 28 18:25:16 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D0611E812D for ; Thu, 28 Jul 2011 18:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbWHWUiLXm62 for ; Thu, 28 Jul 2011 18:25:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 65CE211E8092 for ; Thu, 28 Jul 2011 18:25:15 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6T1OpBv020045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 20:24:54 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6T1OpPk030260 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Jul 2011 06:54:51 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 29 Jul 2011 06:54:51 +0530 From: "Bhatia, Manav (Manav)" To: Mach Chen , "rtg-bfd@ietf.org" Date: Fri, 29 Jul 2011 06:54:49 +0530 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AQHMTXaSGUO8YfsvQESe7fRUbEFVi5UCgIrw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 01:25:16 -0000 Hi Mach, I am not sure I understand why you would want BFD to ensure liveliness of e= ach component link in a LAG. The draft seems to suggest establishing separa= te BFD session for each pair of component interfaces to detect the failures= . Why should BFD be concerned about each component link? I would rather tha= t BFD sprays packets over each component link in a round robin fashion and = brings down the IP interface over a lag only if it misses 3 consecutive pac= kets. Am I missing something? Cheers, Manav -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Mach Chen Sent: Friday, July 29, 2011 4:05 AM To: rtg-bfd@ietf.org Subject: Solicit comments on BFD for Interface draft Hi, We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface= -00) that is about BFD running over interface(e.g., LAG/Bundle interface). = You are very welcome to read the draft and give your comments. Many thanks, Mach From jeff.tantsura@ericsson.com Thu Jul 28 18:45:32 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1D221F85AB for ; Thu, 28 Jul 2011 18:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y699hW7Ke6Bj for ; Thu, 28 Jul 2011 18:45:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2B521F85A4 for ; Thu, 28 Jul 2011 18:45:32 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6T1jNLc025180; Thu, 28 Jul 2011 20:45:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 28 Jul 2011 21:45:19 -0400 From: Jeff Tantsura To: "Bhatia, Manav (Manav)" Date: Thu, 28 Jul 2011 21:45:17 -0400 Subject: Re: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxNkSutMLbwow1zQkCLAZlZPjmBgw== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 01:45:32 -0000 Hi, We have been supporting this mode of BFD over LAG operations for last 5 yea= rs and our customers love it. Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, do= you really want to bring the LAG down? Mach - be aware of patents :) Regards, Jeff On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: > Hi Mach, >=20 > I am not sure I understand why you would want BFD to ensure liveliness of= each component link in a LAG. The draft seems to suggest establishing sepa= rate BFD session for each pair of component interfaces to detect the failur= es. Why should BFD be concerned about each component link? I would rather t= hat BFD sprays packets over each component link in a round robin fashion an= d brings down the IP interface over a lag only if it misses 3 consecutive p= ackets. Am I missing something? >=20 > Cheers, Manav >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Mach Chen > Sent: Friday, July 29, 2011 4:05 AM > To: rtg-bfd@ietf.org > Subject: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interfa= ce-00) that is about BFD running over interface(e.g., LAG/Bundle interface)= . You are very welcome to read the draft and give your comments. >=20 > Many thanks, > Mach From manav.bhatia@alcatel-lucent.com Thu Jul 28 19:18:51 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497ED21F8A6F for ; Thu, 28 Jul 2011 19:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiQQIxQjB8PQ for ; Thu, 28 Jul 2011 19:18:50 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6E21F8A6C for ; Thu, 28 Jul 2011 19:18:50 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6T2IVnC007047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 21:18:33 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6T2IUWl000606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Jul 2011 07:48:30 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 29 Jul 2011 07:48:30 +0530 From: "Bhatia, Manav (Manav)" To: Jeff Tantsura Date: Fri, 29 Jul 2011 07:48:29 +0530 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxNkSutMLbwow1zQkCLAZlZPjmBgwABEhYA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 02:18:51 -0000 Hi Jeff, Let me understand this. If you have an IP interface over a LAG with 5 compo= nent links, then you internally establish 5 BFD sessions with 30ms timeouts= ? You don't need to do this. You could use LACP for lag and BFD for IP connec= tivity - which means BFD should remain up as long as there is reachability = over the lag. IMO it has no business to bother with each individual compone= nt links.=20 Cheers, Manav -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: Friday, July 29, 2011 7:15 AM To: Bhatia, Manav (Manav) Cc: Mach Chen; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Hi, We have been supporting this mode of BFD over LAG operations for last 5 yea= rs and our customers love it. Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, do= you really want to bring the LAG down? Mach - be aware of patents :) Regards, Jeff On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: > Hi Mach, >=20 > I am not sure I understand why you would want BFD to ensure liveliness of= each component link in a LAG. The draft seems to suggest establishing sepa= rate BFD session for each pair of component interfaces to detect the failur= es. Why should BFD be concerned about each component link? I would rather t= hat BFD sprays packets over each component link in a round robin fashion an= d brings down the IP interface over a lag only if it misses 3 consecutive p= ackets. Am I missing something? >=20 > Cheers, Manav >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Mach Chen > Sent: Friday, July 29, 2011 4:05 AM > To: rtg-bfd@ietf.org > Subject: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interfa= ce-00) that is about BFD running over interface(e.g., LAG/Bundle interface)= . You are very welcome to read the draft and give your comments. >=20 > Many thanks, > Mach From rrahman@cisco.com Thu Jul 28 19:24:42 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7174D11E8092 for ; Thu, 28 Jul 2011 19:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgBII-8Vub4o for ; Thu, 28 Jul 2011 19:24:41 -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 A45F011E8084 for ; Thu, 28 Jul 2011 19:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rrahman@cisco.com; l=2036; q=dns/txt; s=iport; t=1311906281; x=1313115881; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AUTI/zdNY9tPsZK9/JMdyT/zDsMmMF8CUKRBd2b3M3w=; b=IDJMyWepp9e1qennRt+C3q53AND4uGl9zYsaBn32ECF1gGtG6YA+nt9Q hyJvCWWIEbdjGZ1Ekf80nITwiMVcxyT/lgh1ax41vrmBp1S8f9saS/7/B +cxUR4DeCHvY7gvv/0mBK8GyEpQCo63h6PE+2YoA0UYLd5R2CEwHazMRL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAL0YMk6tJV2b/2dsb2JhbAAqCwEBAQECARQBIQpFBQcFAgEJEQQBAQsGIwEGARM7DggBAQUXDBuXbI9Ld4h8BKMRnkGFYl8Eh1qQL4ty X-IronPort-AV: E=Sophos;i="4.67,285,1309737600"; d="scan'208";a="7621050" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2011 02:24:41 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6T2OfCc014311; Fri, 29 Jul 2011 02:24:41 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 21:24:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Solicit comments on BFD for Interface draft Date: Thu, 28 Jul 2011 21:24:39 -0500 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA053F36C7@XMB-RCD-204.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxNkSutMLbwow1zQkCLAZlZPjmBgwABH4qA References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Reshad Rahman (rrahman)" To: "Jeff Tantsura" , "Bhatia, Manav (Manav)" X-OriginalArrivalTime: 29 Jul 2011 02:24:40.0803 (UTC) FILETIME=[ABB3EB30:01CC4D96] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 02:24:42 -0000 Also as section 4 of that draft mentions: when one LAG component link is BFD down, the component link is removed from the LAG (I assume this means in forwarding plane and not in control plane) so you can keep your bundle up but you've removed the "bad" component links to avoid traffic loss over that bad link. Regards, Reshad. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Thursday, July 28, 2011 9:45 PM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Hi, We have been supporting this mode of BFD over LAG operations for last 5 years and our customers love it. Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, do you really want to bring the LAG down? Mach - be aware of patents :) Regards, Jeff On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: > Hi Mach, >=20 > I am not sure I understand why you would want BFD to ensure liveliness of each component link in a LAG. The draft seems to suggest establishing separate BFD session for each pair of component interfaces to detect the failures. Why should BFD be concerned about each component link? I would rather that BFD sprays packets over each component link in a round robin fashion and brings down the IP interface over a lag only if it misses 3 consecutive packets. Am I missing something? >=20 > Cheers, Manav >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Friday, July 29, 2011 4:05 AM > To: rtg-bfd@ietf.org > Subject: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD running over interface(e.g., LAG/Bundle interface). You are very welcome to read the draft and give your comments. >=20 > Many thanks, > Mach From rrahman@cisco.com Thu Jul 28 19:25:31 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2612D21F8AF2 for ; Thu, 28 Jul 2011 19:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As7Ys+g747tK for ; Thu, 28 Jul 2011 19:25:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8951E21F8AE6 for ; Thu, 28 Jul 2011 19:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rrahman@cisco.com; l=2603; q=dns/txt; s=iport; t=1311906330; x=1313115930; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4ynEfb59ZNE24raEZGW1Ep3CvAgikJMHZtQ9CNpK7yI=; b=CG/z/MmZgIS9+P8Cz2VJsaV2IhVU1yQyfuUAjK5VVmEGKCw+UnrNFZko orgpv1tqM+WoH4I0OqDDdx55rYL95pHQMwkMZmQwSmLLFYgdL6iNhQiLe 7OY6dnEl5FBd3tYFLrJSHFnkxJ1DhkmcPaEIL9/hAaTERvlNfik+n6Dyw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAALQZMk6tJXG8/2dsb2JhbAAqCwEBAQECARQBIQpFBQcFAgEJEQQBAQsGIwEGARM7DggBAQUBFgwbl2yPS3eIfASjDJ5BhWJfBIdakC+Lcg X-IronPort-AV: E=Sophos;i="4.67,285,1309737600"; d="scan'208";a="7619635" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jul 2011 02:25:30 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6T2PUjP011454; Fri, 29 Jul 2011 02:25:30 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 21:25:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Solicit comments on BFD for Interface draft Date: Thu, 28 Jul 2011 21:25:28 -0500 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA053F36C9@XMB-RCD-204.cisco.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxNkSutMLbwow1zQkCLAZlZPjmBgwABEhYAAAAyYFA= References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Reshad Rahman (rrahman)" To: "Bhatia, Manav (Manav)" , "Jeff Tantsura" X-OriginalArrivalTime: 29 Jul 2011 02:25:29.0402 (UTC) FILETIME=[C8AB89A0:01CC4D96] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 02:25:31 -0000 Hi, I don't think LACP supports sub-second intervals. Also there might be failures which BFD could detect but which LACP doesn't? A bit of a layering violation but if the interface is L3 only... Regards, Reshad. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) Sent: Thursday, July 28, 2011 10:18 PM To: Jeff Tantsura Cc: rtg-bfd@ietf.org Subject: RE: Solicit comments on BFD for Interface draft Hi Jeff, Let me understand this. If you have an IP interface over a LAG with 5 component links, then you internally establish 5 BFD sessions with 30ms timeouts? You don't need to do this. You could use LACP for lag and BFD for IP connectivity - which means BFD should remain up as long as there is reachability over the lag. IMO it has no business to bother with each individual component links.=20 Cheers, Manav -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: Friday, July 29, 2011 7:15 AM To: Bhatia, Manav (Manav) Cc: Mach Chen; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Hi, We have been supporting this mode of BFD over LAG operations for last 5 years and our customers love it. Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, do you really want to bring the LAG down? Mach - be aware of patents :) Regards, Jeff On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: > Hi Mach, >=20 > I am not sure I understand why you would want BFD to ensure liveliness of each component link in a LAG. The draft seems to suggest establishing separate BFD session for each pair of component interfaces to detect the failures. Why should BFD be concerned about each component link? I would rather that BFD sprays packets over each component link in a round robin fashion and brings down the IP interface over a lag only if it misses 3 consecutive packets. Am I missing something? >=20 > Cheers, Manav >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Mach Chen > Sent: Friday, July 29, 2011 4:05 AM > To: rtg-bfd@ietf.org > Subject: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD running over interface(e.g., LAG/Bundle interface). You are very welcome to read the draft and give your comments. >=20 > Many thanks, > Mach From anarora@cisco.com Thu Jul 28 19:44:20 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4921F86BA for ; Thu, 28 Jul 2011 19:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQhFFhCeEcZl for ; Thu, 28 Jul 2011 19:44:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CAEE021F886C for ; Thu, 28 Jul 2011 19:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=anarora@cisco.com; l=3999; q=dns/txt; s=iport; t=1311907458; x=1313117058; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=frPmni7FOIDRidkYywz2LPTlDqNBj2gFoSFBDznd4sQ=; b=JySXJdI7QmWh7c8c0wR9BXXXCMtSocxDCKBKzGH/1PFQbI1SzMRHjkdM rQbnxUaiV1+nzGignc7SQLII5fz+2xkA6Z4Be5j+J0MSE9wqQ1eYxbK4B mTjpEnX+YCq3e/4zl5J93RZP04niiDcjwom2SK7IIaNWhuSLmH7Sr359O Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAK0dMk5Io8UR/2dsb2JhbAAqCwEBAQECARQBIU8FBwUCAQkRBAEBCwYjAQYBEzsOCAEBBQELCwwbl2yPS3eIfASjCp4+hWJfBIcrLZAxi1w X-IronPort-AV: E=Sophos;i="4.67,285,1309737600"; d="scan'208";a="45269611" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 29 Jul 2011 02:44:16 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6T2iGqN004732; Fri, 29 Jul 2011 02:44:16 GMT Received: from xmb-bgl-415.cisco.com ([72.163.129.211]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 08:14:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Solicit comments on BFD for Interface draft Date: Fri, 29 Jul 2011 08:14:12 +0530 Message-ID: <24FF88BE62B5394C83AC8BA2828C9F9B0488AA43@XMB-BGL-415.cisco.com> In-Reply-To: <654701C60BCC7C4EBD533B89D72BDFEA053F36C9@XMB-RCD-204.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxNkSutMLbwow1zQkCLAZlZPjmBgwABEhYAAAAyYFAAAHozcA== References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com><7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <654701C60BCC7C4EBD533B89D72BDFEA053F36C9@XMB-RCD-204.cisco.com> From: "Ankush Arora (anarora)" To: "Reshad Rahman (rrahman)" , "Bhatia, Manav (Manav)" , "Jeff Tantsura" X-OriginalArrivalTime: 29 Jul 2011 02:44:16.0366 (UTC) FILETIME=[686498E0:01CC4D99] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 02:44:20 -0000 Yes that's true. Since LACP doesn't support sub-second intervals, that = is the primary reason, customers like the BFD over each member link = feature.=20 Consider a scenario where you have 4 links in a bundle and min links is = not configured or configured for 2 links. If the third link goes down, so the bundle stays up and will be used. If you spray one packet over each link, then you will never have 3 = consecutive packet failures and BFD will never detect this. LACP would detect this, but you cant have sub-second failure detection = to remove the 3rd link. Even if you had min links =3D max for LACP, for the bundle to be brought = down, you will have to depend on LACP timers. Regards, Ankush This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =A0=A0 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Reshad Rahman (rrahman) Sent: Thursday, July 28, 2011 10:25 PM To: Bhatia, Manav (Manav); Jeff Tantsura Cc: rtg-bfd@ietf.org Subject: RE: Solicit comments on BFD for Interface draft Hi, I don't think LACP supports sub-second intervals. Also there might be failures which BFD could detect but which LACP doesn't? A bit of a layering violation but if the interface is L3 only... Regards, Reshad. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) Sent: Thursday, July 28, 2011 10:18 PM To: Jeff Tantsura Cc: rtg-bfd@ietf.org Subject: RE: Solicit comments on BFD for Interface draft Hi Jeff, Let me understand this. If you have an IP interface over a LAG with 5 component links, then you internally establish 5 BFD sessions with 30ms timeouts? You don't need to do this. You could use LACP for lag and BFD for IP connectivity - which means BFD should remain up as long as there is reachability over the lag. IMO it has no business to bother with each individual component links.=20 Cheers, Manav -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: Friday, July 29, 2011 7:15 AM To: Bhatia, Manav (Manav) Cc: Mach Chen; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Hi, We have been supporting this mode of BFD over LAG operations for last 5 years and our customers love it. Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, do you really want to bring the LAG down? Mach - be aware of patents :) Regards, Jeff On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: > Hi Mach, >=20 > I am not sure I understand why you would want BFD to ensure liveliness of each component link in a LAG. The draft seems to suggest establishing separate BFD session for each pair of component interfaces to detect the failures. Why should BFD be concerned about each component link? I would rather that BFD sprays packets over each component link in a round robin fashion and brings down the IP interface over a lag only if it misses 3 consecutive packets. Am I missing something? >=20 > Cheers, Manav >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Mach Chen > Sent: Friday, July 29, 2011 4:05 AM > To: rtg-bfd@ietf.org > Subject: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD running over interface(e.g., LAG/Bundle interface). You are very welcome to read the draft and give your comments. >=20 > Many thanks, > Mach From mach.chen@huawei.com Fri Jul 29 03:54:23 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7FF21F8B7A for ; Fri, 29 Jul 2011 03:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-1.957, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXOFET0DlM2G for ; Fri, 29 Jul 2011 03:54:22 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 646C121F875C for ; Fri, 29 Jul 2011 03:54:22 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP300AUNCWP0Z@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Fri, 29 Jul 2011 18:53:13 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP300B83CWNOL@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Fri, 29 Jul 2011 18:53:13 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACS07851; Fri, 29 Jul 2011 18:53:12 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 18:52:59 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 18:53:11 +0800 Date: Fri, 29 Jul 2011 10:53:10 +0000 From: Mach Chen Subject: RE: Solicit comments on BFD for Interface draft In-reply-to: <24FF88BE62B5394C83AC8BA2828C9F9B0488AA43@XMB-BGL-415.cisco.com> X-Originating-IP: [172.24.2.41] To: "Ankush Arora (anarora)" , "Reshad Rahman (rrahman)" , "Bhatia, Manav (Manav)" , Jeff Tantsura Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMTXaSGUO8YfsvQESe7fRUbEFVi5UCgIrw//+AwoCAAAlGgIAAAfQAgAAFPACAAP/Kcg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <654701C60BCC7C4EBD533B89D72BDFEA053F36C9@XMB-RCD-204.cisco.com> <24FF88BE62B5394C83AC8BA2828C9F9B0488AA43@XMB-BGL-415.cisco.com> Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 10:54:23 -0000 SGkgQW5rdXNoLCBSZXNoYWQsIE1hbmF2LCBKZWZmIGFuZCBhbGwsDQoNClRoYW5rcyBmb3IgeW91 ciBjb21tZW50cyEgU2VlbXMgdGhhdCBNYW5hdidzIGNvbmNlcm4gaXMgcmVzbG92ZWQ6LSkNCg0K RXhhY3RseSwgc3ViLXNlY29uZCBmYWlsdXJlIGRldGVjdGlvbiBpcyB0aGUgbWFpbiBwdXJwb3Nl IG9mIHRoaXMgZHJhZnQuIA0KDQpBbm90aGVyIG1ldGhvZCBvZiByb3VuZC1yb2JpbiBpcyB0byBz ZW5kIE4gY29uc2VjdXRpdmUgcGFja2V0cyBvdmVyIGVhY2ggbGluayh3aGVyZSBOIGlzIHRoZSBC RkQgTXVsdGlwbGllciksIHRoaXMgbWF5IHByb3Blcmx5IGRldGVjdCB0aGUgZmFpbHVyZSBsaW5r LiBCdXQgZm9yIHRoZSB3b3JzdCBjYXNlLCB5b3UgbWF5IG5lZWQgdG8gc2VuZCBOICogKE0gKyAx KSAtIDEgKHdoZXJlIE0gaXMgdGhlIG51bWJlciBvZiB0aGUgY29tcG9uZW50IGxpbmtzKSBwYWNr ZXRzLCB0aGVuIHlvdSBjb3VsZCBkZXRlY3QgdGhlIGZhbHVyZS4gRXZlbiBzbywgdGhlcmUgbWF5 IGJlIGNhc2VzIChlLmcuLCBwZXJpb2RpYyBsb3NzKSB0aGF0IHRoZSBmYWlsdXJlIGxpbmtzIHN0 aWxsIGNhbiBub3QgYmUgY29ycmVjdGx5IGRldGVjdGVkLiANCiANCkJlc3QgcmVnYXJkcywNCk1h Y2ggDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEFu a3VzaCBBcm9yYSAoYW5hcm9yYSkgW2FuYXJvcmFAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTHE 6jfUwjI5yNUgMTA6NDQNCrW9OiBSZXNoYWQgUmFobWFuIChycmFobWFuKTsgQmhhdGlhLCBNYW5h diAoTWFuYXYpOyBKZWZmIFRhbnRzdXJhDQpDYzogcnRnLWJmZEBpZXRmLm9yZw0K1vfM4jogUkU6 IFNvbGljaXQgY29tbWVudHMgb24gQkZEIGZvciBJbnRlcmZhY2UgZHJhZnQNCg0KWWVzIHRoYXQn cyB0cnVlLiBTaW5jZSBMQUNQIGRvZXNuJ3Qgc3VwcG9ydCBzdWItc2Vjb25kIGludGVydmFscywg dGhhdCBpcyB0aGUgcHJpbWFyeSByZWFzb24sIGN1c3RvbWVycyBsaWtlIHRoZSBCRkQgb3ZlciBl YWNoIG1lbWJlciBsaW5rIGZlYXR1cmUuDQoNCkNvbnNpZGVyIGEgc2NlbmFyaW8gd2hlcmUgeW91 IGhhdmUgNCBsaW5rcyBpbiBhIGJ1bmRsZSBhbmQgbWluIGxpbmtzIGlzIG5vdCBjb25maWd1cmVk IG9yIGNvbmZpZ3VyZWQgZm9yIDIgbGlua3MuDQpJZiB0aGUgdGhpcmQgbGluayBnb2VzIGRvd24s IHNvIHRoZSBidW5kbGUgc3RheXMgdXAgYW5kIHdpbGwgYmUgdXNlZC4NCklmIHlvdSBzcHJheSBv bmUgcGFja2V0IG92ZXIgZWFjaCBsaW5rLCB0aGVuIHlvdSB3aWxsIG5ldmVyIGhhdmUgMyBjb25z ZWN1dGl2ZSBwYWNrZXQgZmFpbHVyZXMgYW5kIEJGRCB3aWxsIG5ldmVyIGRldGVjdCB0aGlzLg0K TEFDUCB3b3VsZCBkZXRlY3QgdGhpcywgYnV0IHlvdSBjYW50IGhhdmUgc3ViLXNlY29uZCBmYWls dXJlIGRldGVjdGlvbiB0byByZW1vdmUgdGhlIDNyZCBsaW5rLg0KRXZlbiBpZiB5b3UgaGFkIG1p biBsaW5rcyA9IG1heCBmb3IgTEFDUCwgZm9yIHRoZSBidW5kbGUgdG8gYmUgYnJvdWdodCBkb3du LCB5b3Ugd2lsbCBoYXZlIHRvIGRlcGVuZCBvbiBMQUNQIHRpbWVycy4NCg0KDQpSZWdhcmRzLA0K QW5rdXNoDQoNCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2 aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dC4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUgcmVjaXBpZW50KSwgcGxlYXNl IGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVz IG9mIHRoaXMgbWVzc2FnZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pDQpTZW50OiBUaHVyc2RheSwgSnVs eSAyOCwgMjAxMSAxMDoyNSBQTQ0KVG86IEJoYXRpYSwgTWFuYXYgKE1hbmF2KTsgSmVmZiBUYW50 c3VyYQ0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBTb2xpY2l0IGNvbW1lbnRz IG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0DQoNCkhpLA0KDQpJIGRvbid0IHRoaW5rIExBQ1Ag c3VwcG9ydHMgc3ViLXNlY29uZCBpbnRlcnZhbHMuIEFsc28gdGhlcmUgbWlnaHQgYmUNCmZhaWx1 cmVzIHdoaWNoIEJGRCBjb3VsZCBkZXRlY3QgYnV0IHdoaWNoIExBQ1AgZG9lc24ndD8gIEEgYml0 IG9mIGENCmxheWVyaW5nIHZpb2xhdGlvbiBidXQgaWYgdGhlIGludGVyZmFjZSBpcyBMMyBvbmx5 Li4uDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uDQpCZWhhbGYgT2YgQmhhdGlhLCBNYW5hdiAoTWFuYXYpDQpTZW50OiBUaHVyc2Rh eSwgSnVseSAyOCwgMjAxMSAxMDoxOCBQTQ0KVG86IEplZmYgVGFudHN1cmENCkNjOiBydGctYmZk QGlldGYub3JnDQpTdWJqZWN0OiBSRTogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVy ZmFjZSBkcmFmdA0KDQpIaSBKZWZmLA0KDQpMZXQgbWUgdW5kZXJzdGFuZCB0aGlzLiBJZiB5b3Ug aGF2ZSBhbiBJUCBpbnRlcmZhY2Ugb3ZlciBhIExBRyB3aXRoIDUNCmNvbXBvbmVudCBsaW5rcywg dGhlbiB5b3UgaW50ZXJuYWxseSBlc3RhYmxpc2ggNSBCRkQgc2Vzc2lvbnMgd2l0aCAzMG1zDQp0 aW1lb3V0cz8NCg0KWW91IGRvbid0IG5lZWQgdG8gZG8gdGhpcy4gWW91IGNvdWxkIHVzZSBMQUNQ IGZvciBsYWcgYW5kIEJGRCBmb3IgSVANCmNvbm5lY3Rpdml0eSAtIHdoaWNoIG1lYW5zIEJGRCBz aG91bGQgcmVtYWluIHVwIGFzIGxvbmcgYXMgdGhlcmUgaXMNCnJlYWNoYWJpbGl0eSBvdmVyIHRo ZSBsYWcuIElNTyBpdCBoYXMgbm8gYnVzaW5lc3MgdG8gYm90aGVyIHdpdGggZWFjaA0KaW5kaXZp ZHVhbCBjb21wb25lbnQgbGlua3MuDQoNCkNoZWVycywgTWFuYXYNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEplZmYgVGFudHN1cmEgW21haWx0bzpqZWZmLnRhbnRzdXJhQGVy aWNzc29uLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAyOSwgMjAxMSA3OjE1IEFNDQpUbzogQmhh dGlhLCBNYW5hdiAoTWFuYXYpDQpDYzogTWFjaCBDaGVuOyBydGctYmZkQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBkcmFmdA0KDQpI aSwNCg0KV2UgaGF2ZSBiZWVuIHN1cHBvcnRpbmcgdGhpcyBtb2RlIG9mIEJGRCBvdmVyIExBRyBv cGVyYXRpb25zIGZvciBsYXN0IDUNCnllYXJzIGFuZCBvdXIgY3VzdG9tZXJzIGxvdmUgaXQuDQoN Ck1hbmF2IC0gaW1hZ2luZSB5b3UgaGF2ZSBsb3N0IDMgb3V0IG9mIDggbGlua3MgYnV0IGRpZG4n dCBoaXQgbWluLWxpbmtzLA0KZG8geW91IHJlYWxseSB3YW50IHRvIGJyaW5nIHRoZSBMQUcgZG93 bj8NCg0KTWFjaCAtIGJlIGF3YXJlIG9mIHBhdGVudHMgOikNCg0KUmVnYXJkcywNCkplZmYNCg0K T24gSnVsIDI4LCAyMDExLCBhdCAyMToyNSwgIkJoYXRpYSwgTWFuYXYgKE1hbmF2KSINCjxtYW5h di5iaGF0aWFAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCg0KPiBIaSBNYWNoLA0KPg0KPiBJ IGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3aHkgeW91IHdvdWxkIHdhbnQgQkZEIHRvIGVuc3Vy ZSBsaXZlbGluZXNzDQpvZiBlYWNoIGNvbXBvbmVudCBsaW5rIGluIGEgTEFHLiBUaGUgZHJhZnQg c2VlbXMgdG8gc3VnZ2VzdCBlc3RhYmxpc2hpbmcNCnNlcGFyYXRlIEJGRCBzZXNzaW9uIGZvciBl YWNoIHBhaXIgb2YgY29tcG9uZW50IGludGVyZmFjZXMgdG8gZGV0ZWN0IHRoZQ0KZmFpbHVyZXMu IFdoeSBzaG91bGQgQkZEIGJlIGNvbmNlcm5lZCBhYm91dCBlYWNoIGNvbXBvbmVudCBsaW5rPyBJ IHdvdWxkDQpyYXRoZXIgdGhhdCBCRkQgc3ByYXlzIHBhY2tldHMgb3ZlciBlYWNoIGNvbXBvbmVu dCBsaW5rIGluIGEgcm91bmQgcm9iaW4NCmZhc2hpb24gYW5kIGJyaW5ncyBkb3duIHRoZSBJUCBp bnRlcmZhY2Ugb3ZlciBhIGxhZyBvbmx5IGlmIGl0IG1pc3NlcyAzDQpjb25zZWN1dGl2ZSBwYWNr ZXRzLiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPg0KPiBDaGVlcnMsIE1hbmF2DQo+DQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIE1hY2gg Q2hlbg0KPiBTZW50OiBGcmlkYXksIEp1bHkgMjksIDIwMTEgNDowNSBBTQ0KPiBUbzogcnRnLWJm ZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJm YWNlIGRyYWZ0DQo+DQo+IEhpLA0KPg0KPiBXZSB1cGxvYWRlZCBhIG5ldw0KZHJhZnQoaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwKSB0aGF0IGlz DQphYm91dCBCRkQgcnVubmluZyBvdmVyIGludGVyZmFjZShlLmcuLCBMQUcvQnVuZGxlIGludGVy ZmFjZSkuIFlvdSBhcmUNCnZlcnkgd2VsY29tZSB0byByZWFkIHRoZSBkcmFmdCBhbmQgZ2l2ZSB5 b3VyIGNvbW1lbnRzLg0KPg0KPiBNYW55IHRoYW5rcywNCj4gTWFjaA0K From shringi@gmail.com Fri Jul 29 04:11:11 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D85F21F85B8 for ; Fri, 29 Jul 2011 04:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDNpsMDCfx5c for ; Fri, 29 Jul 2011 04:11:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 335A421F8559 for ; Fri, 29 Jul 2011 04:11:10 -0700 (PDT) Received: by wwe5 with SMTP id 5so2280435wwe.13 for ; Fri, 29 Jul 2011 04:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=crzsODqwK4w0EqVLiX6OPMm94umvVFIaTwxsJvVq47Y=; b=rG7OP/r+j5ItdV24+OEXLj0YHPCghbjx6uBfkXBoTjEzgFAOC6K8Olz3W6wmZ+ym8+ R0Gmo/XaP0Y9B0azg3ulZ9iTuK0ipgDoHgwKss42/7D/rr1JjBgfKdOVVG3Nco4g34L4 Odvn/uQbO5SQUNf3Ed/+yQyU6LCT0v1QfU4MY= MIME-Version: 1.0 Received: by 10.227.7.32 with SMTP id b32mr1685553wbb.5.1311937869232; Fri, 29 Jul 2011 04:11:09 -0700 (PDT) Received: by 10.216.184.21 with HTTP; Fri, 29 Jul 2011 04:11:09 -0700 (PDT) In-Reply-To: <24FF88BE62B5394C83AC8BA2828C9F9B0488AA43@XMB-BGL-415.cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <654701C60BCC7C4EBD533B89D72BDFEA053F36C9@XMB-RCD-204.cisco.com> <24FF88BE62B5394C83AC8BA2828C9F9B0488AA43@XMB-BGL-415.cisco.com> Date: Fri, 29 Jul 2011 16:41:09 +0530 Message-ID: Subject: Re: Solicit comments on BFD for Interface draft From: Jagrati Shringi To: "Ankush Arora (anarora)" Content-Type: multipart/alternative; boundary=0022159762eaa9bb7104a9335677 Cc: "Reshad Rahman \(rrahman\)" , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 11:11:11 -0000 --0022159762eaa9bb7104a9335677 Content-Type: text/plain; charset=ISO-8859-1 Long LACP timers are relevant for non-receipt of packet, But on seeing a LoS LACP can notify the peer of a failure. It does not have to wait for Second timers to do so. Per link BFD mkes more sense on media where getting LoS is not guranteed. Also per link BFD should not be confused probably with BFD over LAG. Mach, so I am assuming per link BFD session will continue to live on forwardign plane. Will there will be a aggregation on control plane? As link of the LAG can be spread across multiple forwarding planes. Thanks Jagrati On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (anarora) wrote: > Yes that's true. Since LACP doesn't support sub-second intervals, that is > the primary reason, customers like the BFD over each member link feature. > > Consider a scenario where you have 4 links in a bundle and min links is not > configured or configured for 2 links. > If the third link goes down, so the bundle stays up and will be used. > If you spray one packet over each link, then you will never have 3 > consecutive packet failures and BFD will never detect this. > LACP would detect this, but you cant have sub-second failure detection to > remove the 3rd link. > Even if you had min links = max for LACP, for the bundle to be brought > down, you will have to depend on LACP timers. > > > Regards, > Ankush > > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by reply > e-mail and delete all copies of this message. > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf > Of Reshad Rahman (rrahman) > Sent: Thursday, July 28, 2011 10:25 PM > To: Bhatia, Manav (Manav); Jeff Tantsura > Cc: rtg-bfd@ietf.org > Subject: RE: Solicit comments on BFD for Interface draft > > Hi, > > I don't think LACP supports sub-second intervals. Also there might be > failures which BFD could detect but which LACP doesn't? A bit of a > layering violation but if the interface is L3 only... > > Regards, > Reshad. > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, July 28, 2011 10:18 PM > To: Jeff Tantsura > Cc: rtg-bfd@ietf.org > Subject: RE: Solicit comments on BFD for Interface draft > > Hi Jeff, > > Let me understand this. If you have an IP interface over a LAG with 5 > component links, then you internally establish 5 BFD sessions with 30ms > timeouts? > > You don't need to do this. You could use LACP for lag and BFD for IP > connectivity - which means BFD should remain up as long as there is > reachability over the lag. IMO it has no business to bother with each > individual component links. > > Cheers, Manav > > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Friday, July 29, 2011 7:15 AM > To: Bhatia, Manav (Manav) > Cc: Mach Chen; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft > > Hi, > > We have been supporting this mode of BFD over LAG operations for last 5 > years and our customers love it. > > Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, > do you really want to bring the LAG down? > > Mach - be aware of patents :) > > Regards, > Jeff > > On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" > wrote: > > > Hi Mach, > > > > I am not sure I understand why you would want BFD to ensure liveliness > of each component link in a LAG. The draft seems to suggest establishing > separate BFD session for each pair of component interfaces to detect the > failures. Why should BFD be concerned about each component link? I would > rather that BFD sprays packets over each component link in a round robin > fashion and brings down the IP interface over a lag only if it misses 3 > consecutive packets. Am I missing something? > > > > Cheers, Manav > > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Mach Chen > > Sent: Friday, July 29, 2011 4:05 AM > > To: rtg-bfd@ietf.org > > Subject: Solicit comments on BFD for Interface draft > > > > Hi, > > > > We uploaded a new > draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is > about BFD running over interface(e.g., LAG/Bundle interface). You are > very welcome to read the draft and give your comments. > > > > Many thanks, > > Mach > --0022159762eaa9bb7104a9335677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
Long LACP timers are relevant for non-receipt of packet, But on seeing= a LoS LACP can notify the peer of a failure. It does not have to wait for = Second timers to do so. Per link BFD mkes more sense on media where getting= LoS is not guranteed. Also per link BFD should not be confused probably wi= th BFD over LAG. Mach, so I am assuming per link BFD session will continue = to live on forwardign plane. Will there will be a aggregation on control pl= ane? As link of the LAG can be spread across multiple forwarding planes.=A0=
=A0
Thanks
Jagrati

On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (a= narora) <anarora@= cisco.com> wrote:
Yes that's true. Since LACP = doesn't support sub-second intervals, that is the primary reason, custo= mers like the BFD over each member link feature.

Consider a scenario where you have 4 links in a bundle and min links is= not configured or configured for 2 links.
If the third link goes down, = so the bundle stays up and will be used.
If you spray one packet over ea= ch link, then you will never have 3 consecutive packet failures and BFD wil= l never detect this.
LACP would detect this, but you cant have sub-second failure detection to r= emove the 3rd link.
Even if you had min links =3D max for LACP, for the = bundle to be brought down, you will have to depend on LACP timers.


Regards,
Ankush


This e-mail may contain confidential and = privileged material for the sole use of the intended recipient. Any review,= use, distribution or disclosure by others is strictly prohibited. If you a= re not the intended recipient (or authorized to receive for the recipient),= please contact the sender by reply e-mail and delete all copies of this me= ssage. =A0=A0

-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of= Reshad Rahman (rrahman)
Sent: Thursday, July 28, 2011 10:25 PM
To: Bhatia, Manav (Manav); Jeff T= antsura
Cc: rtg-bfd@ietf.org
= Subject: RE: Solicit comments on BFD for Interface draft

Hi,

I don't think LACP supports sub-second intervals. Also there might befailures which BFD could detect but which LACP doesn't? =A0A bit of a=
layering violation but if the interface is L3 only...

Regards, Reshad.

-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
Behalf Of Bha= tia, Manav (Manav)
Sent: Thursday, July 28, 2011 10:18 PM
To: Jeff Tantsura
Cc: rtg-bfd@ietf.org
Subject: RE: Solicit c= omments on BFD for Interface draft

Hi Jeff,

Let me understand= this. If you have an IP interface over a LAG with 5
component links, then you internally establish 5 BFD sessions with 30ms
= timeouts?

You don't need to do this. You could use LACP for lag = and BFD for IP
connectivity - which means BFD should remain up as long a= s there is
reachability over the lag. IMO it has no business to bother with each
in= dividual component links.

Cheers, Manav

-----Original Message= -----
From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]
Sent: Friday, July 29, 2011 7:15 AM
To: Bhatia, Manav (Manav)
Cc: Mac= h Chen; rtg-bfd@ietf.org
Subject= : Re: Solicit comments on BFD for Interface draft

Hi,

We have= been supporting this mode of BFD over LAG operations for last 5
years and our customers love it.

Manav - imagine you have lost 3 out= of 8 links but didn't hit min-links,
do you really want to bring th= e LAG down?

Mach - be aware of patents :)

Regards,
Jeff
On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"
<manav.bhatia@alcatel-lucent= .com> wrote:

> Hi Mach,
>
> I am not sure I un= derstand why you would want BFD to ensure liveliness
of each component link in a LAG. The draft seems to suggest establishingseparate BFD session for each pair of component interfaces to detect thefailures. Why should BFD be concerned about each component link? I would<= br> rather that BFD sprays packets over each component link in a round robinfashion and brings down the IP interface over a lag only if it misses 3consecutive packets. Am I missing something?
>
> Cheers, Manav=
>
> -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> Behal= f Of Mach Chen
> Sent: Friday, July 29, 2011 4:05 AM
> To: rtg-bfd@ietf.org
> Subject: Solicit comments on BFD= for Interface draft
>
> Hi,
>
> We uploaded a new<= br> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)= that is
about BFD running over interface(e.g., LAG/Bundle interface). Y= ou are
very welcome to read the draft and give your comments.
>
> Many= thanks,
> Mach

--0022159762eaa9bb7104a9335677-- From marc@sniff.de Fri Jul 29 15:04:20 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8626211E80B3 for ; Fri, 29 Jul 2011 15:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlJ2O-V+EgIK for ; Fri, 29 Jul 2011 15:04:20 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id BB7F911E8096 for ; Fri, 29 Jul 2011 15:04:19 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8CA4E2AA11; Fri, 29 Jul 2011 22:03:47 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 30 Jul 2011 00:03:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 22:04:20 -0000 Hello Manav, others have already replied but the part "[...] has no business" = triggers now my reply. I deliberately "mis"-understand it. Point is that = this is about business. Customers have pushed their vendors to implement = BFD over LAG component links. Reasons I know - LACP is not fast enough - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers and = Operations, so they would like to use it everywhere - BFDs reputation for being fast and working So now we have 3-4 different implementation for per-cmponent-link BFD = that I know about. Potentially there exists more. Probably not that much = different but enough to make interoperability impossible. It's again = customers who push now for standardization. Thus the draft to find an = agreement :-) Will there be only one solution for "BFD over LAG"? Not sure as I see = two fundamental setups: (a) run BFD on every component link and (b) run = a single BFD session over the LAG interface. They solve different = network setups as far as I can see. Regards, Marc On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: > Hi Jeff, >=20 > Let me understand this. If you have an IP interface over a LAG with 5 = component links, then you internally establish 5 BFD sessions with 30ms = timeouts? >=20 > You don't need to do this. You could use LACP for lag and BFD for IP = connectivity - which means BFD should remain up as long as there is = reachability over the lag. IMO it has no business to bother with each = individual component links.=20 >=20 > Cheers, Manav >=20 > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 > Sent: Friday, July 29, 2011 7:15 AM > To: Bhatia, Manav (Manav) > Cc: Mach Chen; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We have been supporting this mode of BFD over LAG operations for last = 5 years and our customers love it. >=20 > Manav - imagine you have lost 3 out of 8 links but didn't hit = min-links, do you really want to bring the LAG down? >=20 > Mach - be aware of patents :) >=20 > Regards, > Jeff >=20 > On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" = wrote: >=20 >> Hi Mach, >>=20 >> I am not sure I understand why you would want BFD to ensure = liveliness of each component link in a LAG. The draft seems to suggest = establishing separate BFD session for each pair of component interfaces = to detect the failures. Why should BFD be concerned about each component = link? I would rather that BFD sprays packets over each component link in = a round robin fashion and brings down the IP interface over a lag only = if it misses 3 consecutive packets. Am I missing something? >>=20 >> Cheers, Manav >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >> Behalf Of Mach Chen >> Sent: Friday, July 29, 2011 4:05 AM >> To: rtg-bfd@ietf.org >> Subject: Solicit comments on BFD for Interface draft >>=20 >> Hi, >>=20 >> We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. >>=20 >> Many thanks, >> Mach >=20 -- Marc Binderberger From marc@sniff.de Fri Jul 29 15:14:38 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8BD21F8B93 for ; Fri, 29 Jul 2011 15:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-FTaFsjQ7Gr for ; Fri, 29 Jul 2011 15:14:37 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55721F8BB3 for ; Fri, 29 Jul 2011 15:14:36 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3F3E12AA0F; Fri, 29 Jul 2011 22:14:04 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-810476007 From: Marc Binderberger In-Reply-To: Date: Sat, 30 Jul 2011 00:14:01 +0200 Message-Id: <25AFFC54-313A-4DD9-9168-E13D2B8B7C81@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <654701C60BCC7C4EBD533B89D72BDFEA053F36C9@XMB-RCD-204.cisco.com> <24FF88BE62B5394C83AC8BA2828C9F9B0488AA43@XMB-BGL-415.cisco.com> To: Jagrati Shringi X-Mailer: Apple Mail (2.1084) Cc: "Reshad Rahman \(rrahman\)" , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 22:14:38 -0000 --Apple-Mail-1-810476007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Jagrati, > Per link BFD mkes more sense on media where getting LoS is not = guranteed.=20 but a LAG does not have to run on "dark fiber". Exactly the existence of = active equipment - to extend the reach of the Ethernet link or to = aggregate them - that is not "LoS transparent" is a problem in such a = case. Think about one core router in location "A" and the 2nd core router in = location "B" of the same city and a LAG in between. Not uncommon to have = 2 or more sites in larger cities. Regards, Marc On 2011-07-29, at 1:11 PM, Jagrati Shringi wrote: > =20 > Long LACP timers are relevant for non-receipt of packet, But on seeing = a LoS LACP can notify the peer of a failure. It does not have to wait = for Second timers to do so. Per link BFD mkes more sense on media where = getting LoS is not guranteed. Also per link BFD should not be confused = probably with BFD over LAG. Mach, so I am assuming per link BFD session = will continue to live on forwardign plane. Will there will be a = aggregation on control plane? As link of the LAG can be spread across = multiple forwarding planes.=20 > =20 > Thanks > Jagrati >=20 > On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (anarora) = wrote: > Yes that's true. Since LACP doesn't support sub-second intervals, that = is the primary reason, customers like the BFD over each member link = feature. >=20 > Consider a scenario where you have 4 links in a bundle and min links = is not configured or configured for 2 links. > If the third link goes down, so the bundle stays up and will be used. > If you spray one packet over each link, then you will never have 3 = consecutive packet failures and BFD will never detect this. > LACP would detect this, but you cant have sub-second failure detection = to remove the 3rd link. > Even if you had min links =3D max for LACP, for the bundle to be = brought down, you will have to depend on LACP timers. >=20 >=20 > Regards, > Ankush >=20 >=20 > This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Reshad Rahman (rrahman) > Sent: Thursday, July 28, 2011 10:25 PM > To: Bhatia, Manav (Manav); Jeff Tantsura > Cc: rtg-bfd@ietf.org > Subject: RE: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > I don't think LACP supports sub-second intervals. Also there might be > failures which BFD could detect but which LACP doesn't? A bit of a > layering violation but if the interface is L3 only... >=20 > Regards, > Reshad. >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, July 28, 2011 10:18 PM > To: Jeff Tantsura > Cc: rtg-bfd@ietf.org > Subject: RE: Solicit comments on BFD for Interface draft >=20 > Hi Jeff, >=20 > Let me understand this. If you have an IP interface over a LAG with 5 > component links, then you internally establish 5 BFD sessions with = 30ms > timeouts? >=20 > You don't need to do this. You could use LACP for lag and BFD for IP > connectivity - which means BFD should remain up as long as there is > reachability over the lag. IMO it has no business to bother with each > individual component links. >=20 > Cheers, Manav >=20 > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Friday, July 29, 2011 7:15 AM > To: Bhatia, Manav (Manav) > Cc: Mach Chen; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We have been supporting this mode of BFD over LAG operations for last = 5 > years and our customers love it. >=20 > Manav - imagine you have lost 3 out of 8 links but didn't hit = min-links, > do you really want to bring the LAG down? >=20 > Mach - be aware of patents :) >=20 > Regards, > Jeff >=20 > On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" > wrote: >=20 > > Hi Mach, > > > > I am not sure I understand why you would want BFD to ensure = liveliness > of each component link in a LAG. The draft seems to suggest = establishing > separate BFD session for each pair of component interfaces to detect = the > failures. Why should BFD be concerned about each component link? I = would > rather that BFD sprays packets over each component link in a round = robin > fashion and brings down the IP interface over a lag only if it misses = 3 > consecutive packets. Am I missing something? > > > > Cheers, Manav > > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Mach Chen > > Sent: Friday, July 29, 2011 4:05 AM > > To: rtg-bfd@ietf.org > > Subject: Solicit comments on BFD for Interface draft > > > > Hi, > > > > We uploaded a new > draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is > about BFD running over interface(e.g., LAG/Bundle interface). You are > very welcome to read the draft and give your comments. > > > > Many thanks, > > Mach >=20 -- Marc Binderberger --Apple-Mail-1-810476007 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello Jagrati,

 Per link BFD mkes more sense on media where getting LoS is not guranteed. 

but a LAG does not have to run on "dark fiber". Exactly the existence of active equipment - to extend the reach of the Ethernet link or to aggregate them - that is not "LoS transparent" is a problem in such a case.

Think about one core router in location "A" and the 2nd core router in location "B" of the same city and a LAG in between. Not uncommon to have 2 or more sites in larger cities.


Regards, Marc


On 2011-07-29, at 1:11 PM, Jagrati Shringi wrote:

 
Long LACP timers are relevant for non-receipt of packet, But on seeing a LoS LACP can notify the peer of a failure. It does not have to wait for Second timers to do so. Per link BFD mkes more sense on media where getting LoS is not guranteed. Also per link BFD should not be confused probably with BFD over LAG. Mach, so I am assuming per link BFD session will continue to live on forwardign plane. Will there will be a aggregation on control plane? As link of the LAG can be spread across multiple forwarding planes. 
 
Thanks
Jagrati

On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (anarora) <anarora@cisco.com> wrote:
Yes that's true. Since LACP doesn't support sub-second intervals, that is the primary reason, customers like the BFD over each member link feature.

Consider a scenario where you have 4 links in a bundle and min links is not configured or configured for 2 links.
If the third link goes down, so the bundle stays up and will be used.
If you spray one packet over each link, then you will never have 3 consecutive packet failures and BFD will never detect this.
LACP would detect this, but you cant have sub-second failure detection to remove the 3rd link.
Even if you had min links = max for LACP, for the bundle to be brought down, you will have to depend on LACP timers.


Regards,
Ankush


This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.   

-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Reshad Rahman (rrahman)
Sent: Thursday, July 28, 2011 10:25 PM
To: Bhatia, Manav (Manav); Jeff Tantsura
Cc: rtg-bfd@ietf.org
Subject: RE: Solicit comments on BFD for Interface draft

Hi,

I don't think LACP supports sub-second intervals. Also there might be
failures which BFD could detect but which LACP doesn't?  A bit of a
layering violation but if the interface is L3 only...

Regards,
Reshad.

-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, July 28, 2011 10:18 PM
To: Jeff Tantsura
Cc: rtg-bfd@ietf.org
Subject: RE: Solicit comments on BFD for Interface draft

Hi Jeff,

Let me understand this. If you have an IP interface over a LAG with 5
component links, then you internally establish 5 BFD sessions with 30ms
timeouts?

You don't need to do this. You could use LACP for lag and BFD for IP
connectivity - which means BFD should remain up as long as there is
reachability over the lag. IMO it has no business to bother with each
individual component links.

Cheers, Manav

-----Original Message-----
From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]
Sent: Friday, July 29, 2011 7:15 AM
To: Bhatia, Manav (Manav)
Cc: Mach Chen; rtg-bfd@ietf.org
Subject: Re: Solicit comments on BFD for Interface draft

Hi,

We have been supporting this mode of BFD over LAG operations for last 5
years and our customers love it.

Manav - imagine you have lost 3 out of 8 links but didn't hit min-links,
do you really want to bring the LAG down?

Mach - be aware of patents :)

Regards,
Jeff

On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"
<manav.bhatia@alcatel-lucent.com> wrote:

> Hi Mach,
>
> I am not sure I understand why you would want BFD to ensure liveliness
of each component link in a LAG. The draft seems to suggest establishing
separate BFD session for each pair of component interfaces to detect the
failures. Why should BFD be concerned about each component link? I would
rather that BFD sprays packets over each component link in a round robin
fashion and brings down the IP interface over a lag only if it misses 3
consecutive packets. Am I missing something?
>
> Cheers, Manav
>
> -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> Behalf Of Mach Chen
> Sent: Friday, July 29, 2011 4:05 AM
> To: rtg-bfd@ietf.org
> Subject: Solicit comments on BFD for Interface draft
>
> Hi,
>
> We uploaded a new
draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is
about BFD running over interface(e.g., LAG/Bundle interface). You are
very welcome to read the draft and give your comments.
>
> Many thanks,
> Mach


--
Marc Binderberger           <marc@sniff.de>

--Apple-Mail-1-810476007-- From davari@broadcom.com Fri Jul 29 15:21:23 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4FA11E8095 for ; Fri, 29 Jul 2011 15:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLaklUaDebyi for ; Fri, 29 Jul 2011 15:21:23 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDB911E8081 for ; Fri, 29 Jul 2011 15:21:16 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 29 Jul 2011 15:26:18 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Fri, 29 Jul 2011 15:21:07 -0700 From: "Shahram Davari" To: "'marc@sniff.de'" , "'manav.bhatia@alcatel-lucent.com'" Date: Fri, 29 Jul 2011 15:21:06 -0700 Subject: Re: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxOO38ekZPxpfO3TNCZ4F68imDxQwAAlBuO Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266A@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622DEC004U83909557-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 22:21:23 -0000 BFD is a client if IP layer and IP is a client of Ethernet. Therefore BFD i= s technically above LAG and therefore can't be run for individual LAG links= . Doing anything else is not only a layer violation but has consequences. Thx Shahram ----- Original Message ----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Friday, July 29, 2011 03:03 PM=0A= To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Hello Manav, others have already replied but the part "[...] has no business" triggers n= ow my reply. I deliberately "mis"-understand it. Point is that this is abou= t business. Customers have pushed their vendors to implement BFD over LAG c= omponent links. Reasons I know - LACP is not fast enough - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers and Ope= rations, so they would like to use it everywhere - BFDs reputation for being fast and working So now we have 3-4 different implementation for per-cmponent-link BFD that = I know about. Potentially there exists more. Probably not that much differe= nt but enough to make interoperability impossible. It's again customers who= push now for standardization. Thus the draft to find an agreement :-) Will there be only one solution for "BFD over LAG"? Not sure as I see two f= undamental setups: (a) run BFD on every component link and (b) run a singl= e BFD session over the LAG interface. They solve different network setups a= s far as I can see. Regards, Marc On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: > Hi Jeff, >=20 > Let me understand this. If you have an IP interface over a LAG with 5 com= ponent links, then you internally establish 5 BFD sessions with 30ms timeou= ts? >=20 > You don't need to do this. You could use LACP for lag and BFD for IP conn= ectivity - which means BFD should remain up as long as there is reachabilit= y over the lag. IMO it has no business to bother with each individual compo= nent links.=20 >=20 > Cheers, Manav >=20 > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 > Sent: Friday, July 29, 2011 7:15 AM > To: Bhatia, Manav (Manav) > Cc: Mach Chen; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hi, >=20 > We have been supporting this mode of BFD over LAG operations for last 5 y= ears and our customers love it. >=20 > Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, = do you really want to bring the LAG down? >=20 > Mach - be aware of patents :) >=20 > Regards, > Jeff >=20 > On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: >=20 >> Hi Mach, >>=20 >> I am not sure I understand why you would want BFD to ensure liveliness o= f each component link in a LAG. The draft seems to suggest establishing sep= arate BFD session for each pair of component interfaces to detect the failu= res. Why should BFD be concerned about each component link? I would rather = that BFD sprays packets over each component link in a round robin fashion a= nd brings down the IP interface over a lag only if it misses 3 consecutive = packets. Am I missing something? >>=20 >> Cheers, Manav >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >> Behalf Of Mach Chen >> Sent: Friday, July 29, 2011 4:05 AM >> To: rtg-bfd@ietf.org >> Subject: Solicit comments on BFD for Interface draft >>=20 >> Hi, >>=20 >> We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interf= ace-00) that is about BFD running over interface(e.g., LAG/Bundle interface= ). You are very welcome to read the draft and give your comments. >>=20 >> Many thanks, >> Mach >=20 -- Marc Binderberger From marc@sniff.de Fri Jul 29 15:39:14 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922AE21F8BF1 for ; Fri, 29 Jul 2011 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5R8Te8DMNzO for ; Fri, 29 Jul 2011 15:39:14 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id B331921F8BED for ; Fri, 29 Jul 2011 15:39:13 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D95CF2AA0F; Fri, 29 Jul 2011 22:38:41 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266A@SJEXCHCCR02.corp.ad.broadcom.com> Date: Sat, 30 Jul 2011 00:38:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <044337B6-19FD-4CAD-A671-73DF6EA9D3FA@sniff.de> References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266A@SJEXCHCCR02.corp.ad.broadcom.com> To: "Shahram Davari" X-Mailer: Apple Mail (2.1084) Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 22:39:14 -0000 Hello Sharam, sorry but could you please be more specific? "has consequences" means = what exactly for you? The layering has a consequence on the sequence of bringing up LAG links, = BFD sessions etc. The draft is mentioning this. Regards, Marc On 2011-07-30, at 12:21 AM, Shahram Davari wrote: > BFD is a client if IP layer and IP is a client of Ethernet. Therefore = BFD is technically above LAG and therefore can't be run for individual = LAG links. Doing anything else is not only a layer violation but has = consequences. >=20 > Thx > Shahram >=20 > ----- Original Message ----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, July 29, 2011 03:03 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hello Manav, >=20 > others have already replied but the part "[...] has no business" = triggers now my reply. I deliberately "mis"-understand it. Point is that = this is about business. Customers have pushed their vendors to implement = BFD over LAG component links. Reasons I know >=20 > - LACP is not fast enough > - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers = and Operations, so they would like to use it everywhere > - BFDs reputation for being fast and working >=20 >=20 > So now we have 3-4 different implementation for per-cmponent-link BFD = that I know about. Potentially there exists more. Probably not that much = different but enough to make interoperability impossible. It's again = customers who push now for standardization. Thus the draft to find an = agreement :-) >=20 > Will there be only one solution for "BFD over LAG"? Not sure as I see = two fundamental setups: (a) run BFD on every component link and (b) run = a single BFD session over the LAG interface. They solve different = network setups as far as I can see. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >=20 >> Hi Jeff, >>=20 >> Let me understand this. If you have an IP interface over a LAG with 5 = component links, then you internally establish 5 BFD sessions with 30ms = timeouts? >>=20 >> You don't need to do this. You could use LACP for lag and BFD for IP = connectivity - which means BFD should remain up as long as there is = reachability over the lag. IMO it has no business to bother with each = individual component links.=20 >>=20 >> Cheers, Manav >>=20 >> -----Original Message----- >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 >> Sent: Friday, July 29, 2011 7:15 AM >> To: Bhatia, Manav (Manav) >> Cc: Mach Chen; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hi, >>=20 >> We have been supporting this mode of BFD over LAG operations for last = 5 years and our customers love it. >>=20 >> Manav - imagine you have lost 3 out of 8 links but didn't hit = min-links, do you really want to bring the LAG down? >>=20 >> Mach - be aware of patents :) >>=20 >> Regards, >> Jeff >>=20 >> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" = wrote: >>=20 >>> Hi Mach, >>>=20 >>> I am not sure I understand why you would want BFD to ensure = liveliness of each component link in a LAG. The draft seems to suggest = establishing separate BFD session for each pair of component interfaces = to detect the failures. Why should BFD be concerned about each component = link? I would rather that BFD sprays packets over each component link in = a round robin fashion and brings down the IP interface over a lag only = if it misses 3 consecutive packets. Am I missing something? >>>=20 >>> Cheers, Manav >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >>> Behalf Of Mach Chen >>> Sent: Friday, July 29, 2011 4:05 AM >>> To: rtg-bfd@ietf.org >>> Subject: Solicit comments on BFD for Interface draft >>>=20 >>> Hi, >>>=20 >>> We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. >>>=20 >>> Many thanks, >>> Mach >>=20 >=20 > -- > Marc Binderberger >=20 >=20 >=20 -- Marc Binderberger From manav.bhatia@alcatel-lucent.com Fri Jul 29 16:34:16 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E311E80C9 for ; Fri, 29 Jul 2011 16:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrOjJUrJi9Fr for ; Fri, 29 Jul 2011 16:34:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7611E807E for ; Fri, 29 Jul 2011 16:34:15 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6TNY6Ws017370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2011 18:34:09 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6TNY4pB017108 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Jul 2011 05:04:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 30 Jul 2011 05:04:04 +0530 From: "Bhatia, Manav (Manav)" To: Marc Binderberger Date: Sat, 30 Jul 2011 05:04:01 +0530 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxOO2vR9V/plz8GScKcdvCnIQ5KPAACz/7Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> In-Reply-To: <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> 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-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 23:34:16 -0000 Hi Marc, I think the diagnoses is correct, but the medicine isn't! :-) I completely agree that LACP is not fast enough and that operators also wan= t to detect individual component link breakdowns instead of the entire LAG.= If that's the case then folks should use IEEE 802.1ag for individual compo= nent links and BFD for the entire LAG. Are we trying to position BFD as an = IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over comp= onent links since not all links may be ethernet? I think (and this is also what Shahram was alluding to) that BFD is meant t= o detect IP liveliness. This means that if I run BFD over an IP interface i= t should bring it down only when the IP connectivity goes down. Shouldn't B= FD be oblivious to the number of links alive in a LAG as long as the LAG re= mains up and it can reach the other end. It is a simple implementation effo= rt to note the status of each component link of a lag and to bring it down = if the number goes below a certain threshold - You don't need to run BFD ov= er each link! Cheers, Manav > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de]=20 > Sent: Saturday, July 30, 2011 3:34 AM > To: Bhatia, Manav (Manav) > Cc: Jeff Tantsura; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hello Manav, >=20 > others have already replied but the part "[...] has no=20 > business" triggers now my reply. I deliberately=20 > "mis"-understand it. Point is that this is about business.=20 > Customers have pushed their vendors to implement BFD over LAG=20 > component links. Reasons I know >=20 > - LACP is not fast enough > - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 > Designers and Operations, so they would like to use it everywhere > - BFDs reputation for being fast and working >=20 >=20 > So now we have 3-4 different implementation for=20 > per-cmponent-link BFD that I know about. Potentially there=20 > exists more. Probably not that much different but enough to=20 > make interoperability impossible. It's again customers who=20 > push now for standardization. Thus the draft to find an agreement :-) >=20 > Will there be only one solution for "BFD over LAG"? Not sure=20 > as I see two fundamental setups: (a) run BFD on every=20 > component link and (b) run a single BFD session over the LAG=20 > interface. They solve different network setups as far as I can see. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >=20 > > Hi Jeff, > >=20 > > Let me understand this. If you have an IP interface over a=20 > LAG with 5 component links, then you internally establish 5=20 > BFD sessions with 30ms timeouts? > >=20 > > You don't need to do this. You could use LACP for lag and=20 > BFD for IP connectivity - which means BFD should remain up as=20 > long as there is reachability over the lag. IMO it has no=20 > business to bother with each individual component links.=20 > >=20 > > Cheers, Manav > >=20 > > -----Original Message----- > > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > > Sent: Friday, July 29, 2011 7:15 AM > > To: Bhatia, Manav (Manav) > > Cc: Mach Chen; rtg-bfd@ietf.org > > Subject: Re: Solicit comments on BFD for Interface draft > >=20 > > Hi, > >=20 > > We have been supporting this mode of BFD over LAG=20 > operations for last 5 years and our customers love it. > >=20 > > Manav - imagine you have lost 3 out of 8 links but didn't=20 > hit min-links, do you really want to bring the LAG down? > >=20 > > Mach - be aware of patents :) > >=20 > > Regards, > > Jeff > >=20 > > On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 > wrote: > >=20 > >> Hi Mach, > >>=20 > >> I am not sure I understand why you would want BFD to=20 > ensure liveliness of each component link in a LAG. The draft=20 > seems to suggest establishing separate BFD session for each=20 > pair of component interfaces to detect the failures. Why=20 > should BFD be concerned about each component link? I would=20 > rather that BFD sprays packets over each component link in a=20 > round robin fashion and brings down the IP interface over a=20 > lag only if it misses 3 consecutive packets. Am I missing something? > >>=20 > >> Cheers, Manav > >>=20 > >> -----Original Message----- > >> From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On=20 > >> Behalf Of Mach Chen > >> Sent: Friday, July 29, 2011 4:05 AM > >> To: rtg-bfd@ietf.org > >> Subject: Solicit comments on BFD for Interface draft > >>=20 > >> Hi, > >>=20 > >> We uploaded a new=20 > draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 > that is about BFD running over interface(e.g., LAG/Bundle=20 > interface). You are very welcome to read the draft and give=20 > your comments. > >>=20 > >> Many thanks, > >> Mach > >=20 >=20 > -- > Marc Binderberger >=20 > = From nitinb@juniper.net Fri Jul 29 17:16:51 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFCA21F8922 for ; Fri, 29 Jul 2011 17:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8-NPSmyiMca for ; Fri, 29 Jul 2011 17:16:51 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id AADD421F8891 for ; Fri, 29 Jul 2011 17:16:50 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTjNNbbM6c6A6OuXpsTRZxLmGkbEZLdCz@postini.com; Fri, 29 Jul 2011 17:16:50 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 29 Jul 2011 17:13:10 -0700 From: Nitin Bahadur To: "Bhatia, Manav (Manav)" , Marc Binderberger Date: Fri, 29 Jul 2011 17:13:08 -0700 Subject: Re: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxOO2vR9V/plz8GScKcdvCnIQ5KPAACz/7QAAGydqU= Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en 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 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 00:16:51 -0000 I agree with all this in theory. But I think we need service provider reaso= ning as well. Providers who want/use this feature should speak out as to why they want/us= e it....and why ethernet-oam is not sufficient/preferred. Someone mentioned that there are multiple vendors supporting this feature, = so I'm presuming there are multiple customers. Thanks Nitin On 7/29/11 4:34 PM, "Bhatia, Manav (Manav)" wrote: Hi Marc, I think the diagnoses is correct, but the medicine isn't! :-) I completely agree that LACP is not fast enough and that operators also wan= t to detect individual component link breakdowns instead of the entire LAG.= If that's the case then folks should use IEEE 802.1ag for individual compo= nent links and BFD for the entire LAG. Are we trying to position BFD as an = IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over comp= onent links since not all links may be ethernet? I think (and this is also what Shahram was alluding to) that BFD is meant t= o detect IP liveliness. This means that if I run BFD over an IP interface i= t should bring it down only when the IP connectivity goes down. Shouldn't B= FD be oblivious to the number of links alive in a LAG as long as the LAG re= mains up and it can reach the other end. It is a simple implementation effo= rt to note the status of each component link of a lag and to bring it down = if the number goes below a certain threshold - You don't need to run BFD ov= er each link! Cheers, Manav From davari@broadcom.com Fri Jul 29 17:24:17 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BE021F8BFF for ; Fri, 29 Jul 2011 17:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64F37-V0M3ZI for ; Fri, 29 Jul 2011 17:24:16 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id B13BE21F8BFD for ; Fri, 29 Jul 2011 17:24:16 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 29 Jul 2011 17:28:42 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Fri, 29 Jul 2011 17:23:31 -0700 From: "Shahram Davari" To: "'marc@sniff.de'" Date: Fri, 29 Jul 2011 17:23:30 -0700 Subject: Re: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxOQE0Cmv4Tl38GSPiik962NzZUuAADpvI9 Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <044337B6-19FD-4CAD-A671-73DF6EA9D3FA@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622D8FB04U83943417-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 00:24:17 -0000 Hi Each layer should have its own OAM. You should not run OAM on other layers = as proxy for a different layer. This is architecturally wrong.=20 Since LAG hashing is not standard then how can you force a BFD packet to fo= llow a specific link? Should we now start terminating IP layer before LAG l= ayer? Why not just use 802.3ah or 802.1ag? Consequences of layer violations are known. They can range from security is= sues to standards that are not generic and run just under for a specific ap= plication. Regards Shahram ----- Original Message ----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Friday, July 29, 2011 03:38 PM=0A= To: Shahram Davari Cc: 'manav.bhatia@alcatel-lucent.com' ; 'r= tg-bfd@ietf.org' Subject: Re: Solicit comments on BFD for Interface draft Hello Sharam, sorry but could you please be more specific? "has consequences" means what = exactly for you? The layering has a consequence on the sequence of bringing up LAG links, BF= D sessions etc. The draft is mentioning this. Regards, Marc On 2011-07-30, at 12:21 AM, Shahram Davari wrote: > BFD is a client if IP layer and IP is a client of Ethernet. Therefore BFD= is technically above LAG and therefore can't be run for individual LAG lin= ks. Doing anything else is not only a layer violation but has consequences. >=20 > Thx > Shahram >=20 > ----- Original Message ----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, July 29, 2011 03:03 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hello Manav, >=20 > others have already replied but the part "[...] has no business" triggers= now my reply. I deliberately "mis"-understand it. Point is that this is ab= out business. Customers have pushed their vendors to implement BFD over LAG= component links. Reasons I know >=20 > - LACP is not fast enough > - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers and O= perations, so they would like to use it everywhere > - BFDs reputation for being fast and working >=20 >=20 > So now we have 3-4 different implementation for per-cmponent-link BFD tha= t I know about. Potentially there exists more. Probably not that much diffe= rent but enough to make interoperability impossible. It's again customers w= ho push now for standardization. Thus the draft to find an agreement :-) >=20 > Will there be only one solution for "BFD over LAG"? Not sure as I see two= fundamental setups: (a) run BFD on every component link and (b) run a sin= gle BFD session over the LAG interface. They solve different network setups= as far as I can see. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >=20 >> Hi Jeff, >>=20 >> Let me understand this. If you have an IP interface over a LAG with 5 co= mponent links, then you internally establish 5 BFD sessions with 30ms timeo= uts? >>=20 >> You don't need to do this. You could use LACP for lag and BFD for IP con= nectivity - which means BFD should remain up as long as there is reachabili= ty over the lag. IMO it has no business to bother with each individual comp= onent links.=20 >>=20 >> Cheers, Manav >>=20 >> -----Original Message----- >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 >> Sent: Friday, July 29, 2011 7:15 AM >> To: Bhatia, Manav (Manav) >> Cc: Mach Chen; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hi, >>=20 >> We have been supporting this mode of BFD over LAG operations for last 5 = years and our customers love it. >>=20 >> Manav - imagine you have lost 3 out of 8 links but didn't hit min-links,= do you really want to bring the LAG down? >>=20 >> Mach - be aware of patents :) >>=20 >> Regards, >> Jeff >>=20 >> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: >>=20 >>> Hi Mach, >>>=20 >>> I am not sure I understand why you would want BFD to ensure liveliness = of each component link in a LAG. The draft seems to suggest establishing se= parate BFD session for each pair of component interfaces to detect the fail= ures. Why should BFD be concerned about each component link? I would rather= that BFD sprays packets over each component link in a round robin fashion = and brings down the IP interface over a lag only if it misses 3 consecutive= packets. Am I missing something? >>>=20 >>> Cheers, Manav >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >>> Behalf Of Mach Chen >>> Sent: Friday, July 29, 2011 4:05 AM >>> To: rtg-bfd@ietf.org >>> Subject: Solicit comments on BFD for Interface draft >>>=20 >>> Hi, >>>=20 >>> We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-inter= face-00) that is about BFD running over interface(e.g., LAG/Bundle interfac= e). You are very welcome to read the draft and give your comments. >>>=20 >>> Many thanks, >>> Mach >>=20 >=20 > -- > Marc Binderberger >=20 >=20 >=20 -- Marc Binderberger From shringi@gmail.com Fri Jul 29 19:31:34 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2721F8C0B for ; Fri, 29 Jul 2011 19:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7qBA+JW-nJ3 for ; Fri, 29 Jul 2011 19:31:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9CA521F8BBE for ; Fri, 29 Jul 2011 19:31:28 -0700 (PDT) Received: by wyj26 with SMTP id 26so187451wyj.31 for ; Fri, 29 Jul 2011 19:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H47pjXUwORvdYkHdxRaJxLAyJRuMK6+t+wGC9h2v/GQ=; b=Xrpc1Fn22iG8Avsexy94oEWF4VAEXF6QRBX0OYTmTfFmoN1xqJbNVBhNrMACKr6KuN uB4SPhXQUO4t581ma0hAJ9p3xnBplKk+7NGuBzZhWxUmVs6M79CDUN8PAS/ukIibIbH+ io6CtGWimU5ApmlJOzGX6vo4YcFNCNqfJD1oQ= MIME-Version: 1.0 Received: by 10.227.148.220 with SMTP id q28mr2854131wbv.29.1311993087165; Fri, 29 Jul 2011 19:31:27 -0700 (PDT) Received: by 10.216.160.13 with HTTP; Fri, 29 Jul 2011 19:31:27 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> References: <044337B6-19FD-4CAD-A671-73DF6EA9D3FA@sniff.de> <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> Date: Sat, 30 Jul 2011 08:01:27 +0530 Message-ID: Subject: Re: Solicit comments on BFD for Interface draft From: Jagrati Shringi To: Shahram Davari Content-Type: multipart/alternative; boundary=0016e6dd8da7e886c604a9403145 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 02:31:34 -0000 --0016e6dd8da7e886c604a9403145 Content-Type: text/plain; charset=ISO-8859-1 Shahram, This was my concern excatly. We can not force BFd packet to follow a specific link, and it may happen that LAG receives and trasmits from diffrent links. To make this matter even harder these links can live on diffrerent card, if it is a cross-card LAG. If we want to use BFD for link-oam then lets call it something else and that is 802.3 ah and 802.3 ag. 802.3 ag can support sub-second timers I believe. Even then if there is motivation/use-case to have per-link BFD lets keep it saprate rom BFD as a client of IP. Thanks Jagrati On Sat, Jul 30, 2011 at 5:53 AM, Shahram Davari wrote: > Hi > > Each layer should have its own OAM. You should not run OAM on other layers > as proxy for a different layer. This is architecturally wrong. > > Since LAG hashing is not standard then how can you force a BFD packet to > follow a specific link? Should we now start terminating IP layer before LAG > layer? Why not just use 802.3ah or 802.1ag? > > Consequences of layer violations are known. They can range from security > issues to standards that are not generic and run just under for a specific > application. > > Regards > Shahram > > ----- Original Message ----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, July 29, 2011 03:38 PM > To: Shahram Davari > Cc: 'manav.bhatia@alcatel-lucent.com' ; ' > rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft > > Hello Sharam, > > sorry but could you please be more specific? "has consequences" means what > exactly for you? > > The layering has a consequence on the sequence of bringing up LAG links, > BFD sessions etc. The draft is mentioning this. > > > Regards, Marc > > > On 2011-07-30, at 12:21 AM, Shahram Davari wrote: > > > BFD is a client if IP layer and IP is a client of Ethernet. Therefore BFD > is technically above LAG and therefore can't be run for individual LAG > links. Doing anything else is not only a layer violation but has > consequences. > > > > Thx > > Shahram > > > > ----- Original Message ----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Friday, July 29, 2011 03:03 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-bfd@ietf.org > > Subject: Re: Solicit comments on BFD for Interface draft > > > > Hello Manav, > > > > others have already replied but the part "[...] has no business" triggers > now my reply. I deliberately "mis"-understand it. Point is that this is > about business. Customers have pushed their vendors to implement BFD over > LAG component links. Reasons I know > > > > - LACP is not fast enough > > - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers and > Operations, so they would like to use it everywhere > > - BFDs reputation for being fast and working > > > > > > So now we have 3-4 different implementation for per-cmponent-link BFD > that I know about. Potentially there exists more. Probably not that much > different but enough to make interoperability impossible. It's again > customers who push now for standardization. Thus the draft to find an > agreement :-) > > > > Will there be only one solution for "BFD over LAG"? Not sure as I see two > fundamental setups: (a) run BFD on every component link and (b) run a > single BFD session over the LAG interface. They solve different network > setups as far as I can see. > > > > > > Regards, Marc > > > > > > > > On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: > > > >> Hi Jeff, > >> > >> Let me understand this. If you have an IP interface over a LAG with 5 > component links, then you internally establish 5 BFD sessions with 30ms > timeouts? > >> > >> You don't need to do this. You could use LACP for lag and BFD for IP > connectivity - which means BFD should remain up as long as there is > reachability over the lag. IMO it has no business to bother with each > individual component links. > >> > >> Cheers, Manav > >> > >> -----Original Message----- > >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > >> Sent: Friday, July 29, 2011 7:15 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Mach Chen; rtg-bfd@ietf.org > >> Subject: Re: Solicit comments on BFD for Interface draft > >> > >> Hi, > >> > >> We have been supporting this mode of BFD over LAG operations for last 5 > years and our customers love it. > >> > >> Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, > do you really want to bring the LAG down? > >> > >> Mach - be aware of patents :) > >> > >> Regards, > >> Jeff > >> > >> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" < > manav.bhatia@alcatel-lucent.com> wrote: > >> > >>> Hi Mach, > >>> > >>> I am not sure I understand why you would want BFD to ensure liveliness > of each component link in a LAG. The draft seems to suggest establishing > separate BFD session for each pair of component interfaces to detect the > failures. Why should BFD be concerned about each component link? I would > rather that BFD sprays packets over each component link in a round robin > fashion and brings down the IP interface over a lag only if it misses 3 > consecutive packets. Am I missing something? > >>> > >>> Cheers, Manav > >>> > >>> -----Original Message----- > >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > >>> Behalf Of Mach Chen > >>> Sent: Friday, July 29, 2011 4:05 AM > >>> To: rtg-bfd@ietf.org > >>> Subject: Solicit comments on BFD for Interface draft > >>> > >>> Hi, > >>> > >>> We uploaded a new draft( > http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD > running over interface(e.g., LAG/Bundle interface). You are very welcome to > read the draft and give your comments. > >>> > >>> Many thanks, > >>> Mach > >> > > > > -- > > Marc Binderberger > > > > > > > > -- > Marc Binderberger > > > > --0016e6dd8da7e886c604a9403145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Shahram,
=A0
This was my concern excatly. We can not force BFd packet to follow a s= pecific link, and it may happen that LAG receives and trasmits from diffren= t links. To make this matter even harder these links can live on diffrerent= card, if it is a cross-card LAG. If we want to use BFD for link-oam then l= ets call it something else and that is 802.3 ah and 802.3 ag. 802.3 ag can = support sub-second timers I believe. Even then if there is motivation/use-c= ase to have per-link BFD lets keep it saprate rom BFD as a client of IP.
=A0
Thanks
Jagrati=A0

On Sat, Jul 30, 2011 at 5:53 AM, Shahram Davari = <davari@broadcom.com> wrote:
Hi

Each layer should have= its own OAM. You should not run OAM on other layers as proxy for a differe= nt layer. This is architecturally wrong.

Since LAG hashing is not standard then how can you force a BFD packet t= o follow a specific link? Should we now start terminating IP layer before L= AG layer? Why not just use 802.3ah or 802.1ag?

Consequences of layer= violations are known. They can range from security issues to standards tha= t are not generic and run just under for a specific application.

Regards
Shahram

----- Original Message -----
From: Marc Binderberger= [mailto:marc@sniff.de]
Sent: Friday, July 29, 2011 03:38 PM
To: Shahram Davari
Cc: '= ;manav= .bhatia@alcatel-lucent.com' <manav.bhatia@alcatel-lucent.com>; = 'rtg-bfd@ietf.org= ' <rtg-bfd= @ietf.org>
Subject: Re: Solicit comments on BFD for Interface draft

Hello Shara= m,

sorry but could you please be more specific? "has consequenc= es" means what exactly for you?

The layering has a consequence = on the sequence of bringing up LAG links, BFD sessions etc. The draft is me= ntioning this.


Regards, Marc


On 2011-07-30, at 12:21 AM, Shahram Davari= wrote:

> BFD is a client if IP layer and IP is a client of Ether= net. Therefore BFD is technically above LAG and therefore can't be run = for individual LAG links. Doing anything else is not only a layer violation= but has consequences.
>
> Thx
> Shahram
>
> ----- Original Message ---= --
> From: Marc Binderberger [mailto:marc@sniff.de]
> Sent: Friday, July 29, 2011 0= 3:03 PM
> To: Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com>
>= ; Cc: rtg-bfd@ietf.or= g <rtg-bfd@iet= f.org>
> Subject: Re: Solicit comments on BFD for Interface draft
>
&g= t; Hello Manav,
>
> others have already replied but the part &q= uot;[...] has no business" triggers now my reply. I deliberately "= ;mis"-understand it. Point is that this is about business. Customers h= ave pushed their vendors to implement BFD over LAG component links. Reasons= I know
>
> - LACP is not fast enough
> - BFD in it's IP form (I= P+UDP+BFD) is understood by Telco Designers and Operations, so they would l= ike to use it everywhere
> - BFDs reputation for being fast and worki= ng
>
>
> So now we have 3-4 different implementation for per-cm= ponent-link BFD that I know about. Potentially there exists more. Probably = not that much different but enough to make interoperability impossible. It&= #39;s again customers who push now for standardization. Thus the draft to f= ind an agreement :-)
>
> Will there be only one solution for "BFD over LAG"? = Not sure as I see two fundamental setups: (a) run BFD on every component li= nk =A0and (b) run a single BFD session over the LAG interface. They solve d= ifferent network setups as far as I can see.
>
>
> Regards, Marc
>
>
>
> On 2011-= 07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote:
>
>> Hi Jeff= ,
>>
>> Let me understand this. If you have an IP interfa= ce over a LAG with 5 component links, then you internally establish 5 BFD s= essions with 30ms timeouts?
>>
>> You don't need to do this. You could use LACP for = lag and BFD for IP connectivity - which means BFD should remain up as long = as there is reachability over the lag. IMO it has no business to bother wit= h each individual component links.
>>
>> Cheers, Manav
>>
>> -----Original Me= ssage-----
>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]
>> Sent: Friday, July 29, 2011 7:15 AM
>> To: Bhatia, Manav = (Manav)
>> Cc: Mach Chen; rtg-bfd@ietf.org
>> Subject: Re: Solicit comment= s on BFD for Interface draft
>>
>> Hi,
>>
>> We have been supporting th= is mode of BFD over LAG operations for last 5 years and our customers love = it.
>>
>> Manav - imagine you have lost 3 out of 8 links = but didn't hit min-links, do you really want to bring the LAG down?
>>
>> Mach - be aware of patents :)
>>
>> = Regards,
>> Jeff
>>
>> On Jul 28, 2011, at 21:25= , "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> w= rote:
>>
>>> Hi Mach,
>>>
>>> I am not = sure I understand why you would want BFD to ensure liveliness of each compo= nent link in a LAG. The draft seems to suggest establishing separate BFD se= ssion for each pair of component interfaces to detect the failures. Why sho= uld BFD be concerned about each component link? I would rather that BFD spr= ays packets over each component link in a round robin fashion and brings do= wn the IP interface over a lag only if it misses 3 consecutive packets. Am = I missing something?
>>>
>>> Cheers, Manav
>>>
>>> = -----Original Message-----
>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces= @ietf.org] On
>>> Behalf Of Mach Chen
>>> Sent: Friday, July 29, 201= 1 4:05 AM
>>> To: rtg-bfd@ietf.org
>>> Subject: Solicit comments on = BFD for Interface draft
>>>
>>> Hi,
>>>
>>> We uploade= d a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface= -00) that is about BFD running over interface(e.g., LAG/Bundle interfac= e). You are very welcome to read the draft and give your comments.
>>>
>>> Many thanks,
>>> Mach
>><= br>>
> --
> Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>
><= br>>
>

--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>




--0016e6dd8da7e886c604a9403145-- From vishwas.ietf@gmail.com Fri Jul 29 19:39:59 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC5521F8C29 for ; Fri, 29 Jul 2011 19:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=0.896, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqBrvBfWZZsF for ; Fri, 29 Jul 2011 19:39:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4208721F8C27 for ; Fri, 29 Jul 2011 19:39:58 -0700 (PDT) Received: by gxk19 with SMTP id 19so3447281gxk.31 for ; Fri, 29 Jul 2011 19:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z07aKxHAKx6phbVMyr4S3jqesPIe5qYB2gZ7bFvOpRk=; b=lk1nSSOm9nUl3DpSGzqWXr4SQU7F6K7uCV9E9M8tLQpdT8NkML/c70Og/tFQGHnZI8 toysmjPh1F/HnrFtCzdI0VRQQJJAUaYkkhcKIqUIGmwtCMu9fjl+0kuuf6+GgFvkyxg6 4MGe5hTyVBxNqjySJg397Rzigv/y8uG5Kv+sc= MIME-Version: 1.0 Received: by 10.91.194.4 with SMTP id w4mr1786025agp.145.1311993596026; Fri, 29 Jul 2011 19:39:56 -0700 (PDT) Received: by 10.91.128.15 with HTTP; Fri, 29 Jul 2011 19:39:55 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> References: <044337B6-19FD-4CAD-A671-73DF6EA9D3FA@sniff.de> <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 29 Jul 2011 19:39:55 -0700 Message-ID: Subject: Re: Solicit comments on BFD for Interface draft From: Vishwas Manral To: Shahram Davari Content-Type: multipart/alternative; boundary=0016e64603203d200804a94050cb Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 02:39:59 -0000 --0016e64603203d200804a94050cb Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, I agree with what you say. We should not run BFD with UDP encapsulation to send particular packets over particular links. However you have to remember that the BFD protocol byitself is agnostic to the transport over which it works. I remember I had brought up the issue of Ethernet encapsualtion of BFD, as we had customer requirements for the same. If we run BFD directly over Layer-2 it can be used as the CC mechanims for the same. One interesting point here is by using the same OAM across layers, there are fewer things to learn for operators, and cheaper to design for the product developers. I am sure it is true for the ASIC companies too. Thanks, Vishwas On Fri, Jul 29, 2011 at 5:23 PM, Shahram Davari wrote: > Hi > > Each layer should have its own OAM. You should not run OAM on other layers > as proxy for a different layer. This is architecturally wrong. > > Since LAG hashing is not standard then how can you force a BFD packet to > follow a specific link? Should we now start terminating IP layer before LAG > layer? Why not just use 802.3ah or 802.1ag? > > Consequences of layer violations are known. They can range from security > issues to standards that are not generic and run just under for a specific > application. > > Regards > Shahram > > ----- Original Message ----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, July 29, 2011 03:38 PM > To: Shahram Davari > Cc: 'manav.bhatia@alcatel-lucent.com' ; ' > rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft > > Hello Sharam, > > sorry but could you please be more specific? "has consequences" means what > exactly for you? > > The layering has a consequence on the sequence of bringing up LAG links, > BFD sessions etc. The draft is mentioning this. > > > Regards, Marc > > > On 2011-07-30, at 12:21 AM, Shahram Davari wrote: > > > BFD is a client if IP layer and IP is a client of Ethernet. Therefore BFD > is technically above LAG and therefore can't be run for individual LAG > links. Doing anything else is not only a layer violation but has > consequences. > > > > Thx > > Shahram > > > > ----- Original Message ----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Friday, July 29, 2011 03:03 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-bfd@ietf.org > > Subject: Re: Solicit comments on BFD for Interface draft > > > > Hello Manav, > > > > others have already replied but the part "[...] has no business" triggers > now my reply. I deliberately "mis"-understand it. Point is that this is > about business. Customers have pushed their vendors to implement BFD over > LAG component links. Reasons I know > > > > - LACP is not fast enough > > - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers and > Operations, so they would like to use it everywhere > > - BFDs reputation for being fast and working > > > > > > So now we have 3-4 different implementation for per-cmponent-link BFD > that I know about. Potentially there exists more. Probably not that much > different but enough to make interoperability impossible. It's again > customers who push now for standardization. Thus the draft to find an > agreement :-) > > > > Will there be only one solution for "BFD over LAG"? Not sure as I see two > fundamental setups: (a) run BFD on every component link and (b) run a > single BFD session over the LAG interface. They solve different network > setups as far as I can see. > > > > > > Regards, Marc > > > > > > > > On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: > > > >> Hi Jeff, > >> > >> Let me understand this. If you have an IP interface over a LAG with 5 > component links, then you internally establish 5 BFD sessions with 30ms > timeouts? > >> > >> You don't need to do this. You could use LACP for lag and BFD for IP > connectivity - which means BFD should remain up as long as there is > reachability over the lag. IMO it has no business to bother with each > individual component links. > >> > >> Cheers, Manav > >> > >> -----Original Message----- > >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > >> Sent: Friday, July 29, 2011 7:15 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Mach Chen; rtg-bfd@ietf.org > >> Subject: Re: Solicit comments on BFD for Interface draft > >> > >> Hi, > >> > >> We have been supporting this mode of BFD over LAG operations for last 5 > years and our customers love it. > >> > >> Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, > do you really want to bring the LAG down? > >> > >> Mach - be aware of patents :) > >> > >> Regards, > >> Jeff > >> > >> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" < > manav.bhatia@alcatel-lucent.com> wrote: > >> > >>> Hi Mach, > >>> > >>> I am not sure I understand why you would want BFD to ensure liveliness > of each component link in a LAG. The draft seems to suggest establishing > separate BFD session for each pair of component interfaces to detect the > failures. Why should BFD be concerned about each component link? I would > rather that BFD sprays packets over each component link in a round robin > fashion and brings down the IP interface over a lag only if it misses 3 > consecutive packets. Am I missing something? > >>> > >>> Cheers, Manav > >>> > >>> -----Original Message----- > >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > >>> Behalf Of Mach Chen > >>> Sent: Friday, July 29, 2011 4:05 AM > >>> To: rtg-bfd@ietf.org > >>> Subject: Solicit comments on BFD for Interface draft > >>> > >>> Hi, > >>> > >>> We uploaded a new draft( > http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD > running over interface(e.g., LAG/Bundle interface). You are very welcome to > read the draft and give your comments. > >>> > >>> Many thanks, > >>> Mach > >> > > > > -- > > Marc Binderberger > > > > > > > > -- > Marc Binderberger > > > > --0016e64603203d200804a94050cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahram,
=A0
I agree with what you say. We should not run BFD with UDP encapsulatio= n to send particular packets over particular links.
=A0
However you have to remember that the BFD protocol byitself is agnosti= c to the transport over which it works. I remember I had brought up the iss= ue of Ethernet encapsualtion of BFD, as we had customer requirements for th= e same. If we run BFD directly over Layer-2 it can be used as the CC mechan= ims for the same.
=A0
One interesting point here is by using the same OAM across layers, the= re are fewer things to learn for operators, and cheaper to design for the p= roduct developers. I am sure it is true for the ASIC companies too.
=A0
Thanks,
Vishwas
On Fri, Jul 29, 2011 at 5:23 PM, Shahram Davari = <davari@broadco= m.com> wrote:
Hi

Each layer should have= its own OAM. You should not run OAM on other layers as proxy for a differe= nt layer. This is architecturally wrong.

Since LAG hashing is not standard then how can you force a BFD packet t= o follow a specific link? Should we now start terminating IP layer before L= AG layer? Why not just use 802.3ah or 802.1ag?

Consequences of layer= violations are known. They can range from security issues to standards tha= t are not generic and run just under for a specific application.

Regards
Shahram

----- Original Message -----
From: Marc= Binderberger [mailto:marc@sniff.de]
Sent: Friday, July 29, 2011 03:38 PM
To: Shahram Davar= i
Cc: 'manav.bhat= ia@alcatel-lucent.com' <manav.bhatia@alcatel-lucent.com>; 'rtg-bfd@ietf.org' <rtg-bfd@ietf.org>
Subject: Re: Solicit comments on BFD for Interface draft

Hello Shara= m,

sorry but could you please be more specific? "has consequenc= es" means what exactly for you?

The layering has a consequence = on the sequence of bringing up LAG links, BFD sessions etc. The draft is me= ntioning this.


Regards, Marc


On 2011-07-30, at 12:21 AM, Shahram Davari= wrote:

> BFD is a client if IP layer and IP is a client of Ether= net. Therefore BFD is technically above LAG and therefore can't be run = for individual LAG links. Doing anything else is not only a layer violation= but has consequences.
>
> Thx
> Shahram
>
> ----- Original Message ---= --
> From: Marc Binderberger [mailto:marc@sniff.de]
> Sent: Friday, July 29, 2011 03:03 PM
> To= : Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com>
> Cc: rtg-bfd@ietf.org <rtg-bfd@ietf.org>
> Subject: Re= : Solicit comments on BFD for Interface draft
>
> Hello Manav,<= br> >
> others have already replied but the part "[...] has no bu= siness" triggers now my reply. I deliberately "mis"-understa= nd it. Point is that this is about business. Customers have pushed their ve= ndors to implement BFD over LAG component links. Reasons I know
>
> - LACP is not fast enough
> - BFD in it's IP form (I= P+UDP+BFD) is understood by Telco Designers and Operations, so they would l= ike to use it everywhere
> - BFDs reputation for being fast and worki= ng
>
>
> So now we have 3-4 different implementation for per-cm= ponent-link BFD that I know about. Potentially there exists more. Probably = not that much different but enough to make interoperability impossible. It&= #39;s again customers who push now for standardization. Thus the draft to f= ind an agreement :-)
>
> Will there be only one solution for "BFD over LAG"? = Not sure as I see two fundamental setups: (a) run BFD on every component li= nk =A0and (b) run a single BFD session over the LAG interface. They solve d= ifferent network setups as far as I can see.
>
>
> Regards, Marc
>
>
>
> On 2011-= 07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote:
>
>> Hi Jeff= ,
>>
>> Let me understand this. If you have an IP interfa= ce over a LAG with 5 component links, then you internally establish 5 BFD s= essions with 30ms timeouts?
>>
>> You don't need to do this. You could use LACP for = lag and BFD for IP connectivity - which means BFD should remain up as long = as there is reachability over the lag. IMO it has no business to bother wit= h each individual component links.
>>
>> Cheers, Manav
>>
>> -----Original Me= ssage-----
>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]
>> Sent: Fri= day, July 29, 2011 7:15 AM
>> To: Bhatia, Manav (Manav)
>> Cc: Mach Chen; rtg-bfd@ietf.org
>> Subject: Re: Solici= t comments on BFD for Interface draft
>>
>> Hi,
>&g= t;
>> We have been supporting this mode of BFD over LAG operations for l= ast 5 years and our customers love it.
>>
>> Manav - imag= ine you have lost 3 out of 8 links but didn't hit min-links, do you rea= lly want to bring the LAG down?
>>
>> Mach - be aware of patents :)
>>
>> = Regards,
>> Jeff
>>
>> On Jul 28, 2011, at 21:25= , "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> wrote:
>>
>>> Hi Mach,
>>>
>>> I am not = sure I understand why you would want BFD to ensure liveliness of each compo= nent link in a LAG. The draft seems to suggest establishing separate BFD se= ssion for each pair of component interfaces to detect the failures. Why sho= uld BFD be concerned about each component link? I would rather that BFD spr= ays packets over each component link in a round robin fashion and brings do= wn the IP interface over a lag only if it misses 3 consecutive packets. Am = I missing something?
>>>
>>> Cheers, Manav
>>>
>>> = -----Original Message-----
>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
>>> Behalf Of Mach Chen
>>> Sent: Friday, July 29, 201= 1 4:05 AM
>>> To: rtg-bfd@i= etf.org
>>> Subject: Solicit comments on BFD for Interface = draft
>>>
>>> Hi,
>>>
>>> We uploade= d a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface= -00) that is about BFD running over interface(e.g., LAG/Bundle interfac= e). You are very welcome to read the draft and give your comments.
>>>
>>> Many thanks,
>>> Mach
>><= br>>
> --
> Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>
>
>
>
--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <= marc@sniff.de>




--0016e64603203d200804a94050cb-- From marc@sniff.de Sat Jul 30 01:31:58 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9661D21F87ED for ; Sat, 30 Jul 2011 01:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmrPPLDjla0G for ; Sat, 30 Jul 2011 01:31:57 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6385721F87C2 for ; Sat, 30 Jul 2011 01:31:54 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id BA36F2AA0F; Sat, 30 Jul 2011 08:31:21 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> Date: Sat, 30 Jul 2011 10:31:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> To: "Shahram Davari" X-Mailer: Apple Mail (2.1084) Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 08:31:58 -0000 Hello Sharam, second time you make generic statements but avoid concrete details. I'm = sorry to say it but this is not the way to run a discussion. I do appreciate your warning about layer violation. I fully respect your = personal style of designing and am interested to learn from you. But = establishing a dogma in a technical discussion doesn't make sense. The last paragraphs of section 2 and 3 pick the topic of layer violation = up, we only don't name it this way but focus on the result. If you think = this needs more attention in the text - I'm open to constructive = comments. That's why we are here on the list I think :-) Thanks & Regards, Marc On 2011-07-30, at 2:23 AM, Shahram Davari wrote: > Hi >=20 > Each layer should have its own OAM. You should not run OAM on other = layers as proxy for a different layer. This is architecturally wrong.=20 >=20 > Since LAG hashing is not standard then how can you force a BFD packet = to follow a specific link? Should we now start terminating IP layer = before LAG layer? Why not just use 802.3ah or 802.1ag? >=20 > Consequences of layer violations are known. They can range from = security issues to standards that are not generic and run just under for = a specific application. >=20 > Regards > Shahram >=20 > ----- Original Message ----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, July 29, 2011 03:38 PM > To: Shahram Davari > Cc: 'manav.bhatia@alcatel-lucent.com' = ; 'rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hello Sharam, >=20 > sorry but could you please be more specific? "has consequences" means = what exactly for you? >=20 > The layering has a consequence on the sequence of bringing up LAG = links, BFD sessions etc. The draft is mentioning this. >=20 >=20 > Regards, Marc >=20 >=20 > On 2011-07-30, at 12:21 AM, Shahram Davari wrote: >=20 >> BFD is a client if IP layer and IP is a client of Ethernet. Therefore = BFD is technically above LAG and therefore can't be run for individual = LAG links. Doing anything else is not only a layer violation but has = consequences. >>=20 >> Thx >> Shahram >>=20 >> ----- Original Message ----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Friday, July 29, 2011 03:03 PM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hello Manav, >>=20 >> others have already replied but the part "[...] has no business" = triggers now my reply. I deliberately "mis"-understand it. Point is that = this is about business. Customers have pushed their vendors to implement = BFD over LAG component links. Reasons I know >>=20 >> - LACP is not fast enough >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers = and Operations, so they would like to use it everywhere >> - BFDs reputation for being fast and working >>=20 >>=20 >> So now we have 3-4 different implementation for per-cmponent-link BFD = that I know about. Potentially there exists more. Probably not that much = different but enough to make interoperability impossible. It's again = customers who push now for standardization. Thus the draft to find an = agreement :-) >>=20 >> Will there be only one solution for "BFD over LAG"? Not sure as I see = two fundamental setups: (a) run BFD on every component link and (b) run = a single BFD session over the LAG interface. They solve different = network setups as far as I can see. >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Jeff, >>>=20 >>> Let me understand this. If you have an IP interface over a LAG with = 5 component links, then you internally establish 5 BFD sessions with = 30ms timeouts? >>>=20 >>> You don't need to do this. You could use LACP for lag and BFD for IP = connectivity - which means BFD should remain up as long as there is = reachability over the lag. IMO it has no business to bother with each = individual component links.=20 >>>=20 >>> Cheers, Manav >>>=20 >>> -----Original Message----- >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 >>> Sent: Friday, July 29, 2011 7:15 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Mach Chen; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hi, >>>=20 >>> We have been supporting this mode of BFD over LAG operations for = last 5 years and our customers love it. >>>=20 >>> Manav - imagine you have lost 3 out of 8 links but didn't hit = min-links, do you really want to bring the LAG down? >>>=20 >>> Mach - be aware of patents :) >>>=20 >>> Regards, >>> Jeff >>>=20 >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" = wrote: >>>=20 >>>> Hi Mach, >>>>=20 >>>> I am not sure I understand why you would want BFD to ensure = liveliness of each component link in a LAG. The draft seems to suggest = establishing separate BFD session for each pair of component interfaces = to detect the failures. Why should BFD be concerned about each component = link? I would rather that BFD sprays packets over each component link in = a round robin fashion and brings down the IP interface over a lag only = if it misses 3 consecutive packets. Am I missing something? >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >>>> Behalf Of Mach Chen >>>> Sent: Friday, July 29, 2011 4:05 AM >>>> To: rtg-bfd@ietf.org >>>> Subject: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. >>>>=20 >>>> Many thanks, >>>> Mach >>>=20 >>=20 >> -- >> Marc Binderberger >>=20 >>=20 >>=20 >=20 > -- > Marc Binderberger >=20 >=20 >=20 -- Marc Binderberger From marc@sniff.de Sat Jul 30 03:32:29 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D3C21F8745 for ; Sat, 30 Jul 2011 03:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpjWHspInswj for ; Sat, 30 Jul 2011 03:32:28 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id D65F321F86AA for ; Sat, 30 Jul 2011 03:32:27 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 227822AA0F; Sat, 30 Jul 2011 10:31:55 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-854744939 From: Marc Binderberger In-Reply-To: Date: Sat, 30 Jul 2011 12:31:50 +0200 Message-Id: <27D2104E-CDE3-4D12-9C91-F0DD5D174B89@sniff.de> References: <044337B6-19FD-4CAD-A671-73DF6EA9D3FA@sniff.de> <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> To: Jagrati Shringi X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 10:32:29 -0000 --Apple-Mail-2-854744939 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Jagrati, your first points seem to be more an implementation discussion, not a = principal problem as at least 3 teams have managed to overcome the = issues you mention. We are not competing against LACP here. We are offering a different = solution, thus we name it BFD and not 802.3-something and propose it on = the IETF BFD list. I admit using it instead/in parallel to LACP is what some = implementations are doing and what the authors documented with section 4 = as an example. But we are not restricted to this scenario. What is does = is providing information from another layer into "BFD". Whatever you = make out of the information (*). Could it be done with BFD-over-Ethernet frames? Probably. I first = thought into this direction myself. The relevant point is it turned out = we don't have to and can stick to what we and customers know: BFD using = IP/UDP. =20 Regards, Marc (*: maybe we have to define this "whatever" for interoperability. = Discussion will show :-) On 2011-07-30, at 4:31 AM, Jagrati Shringi wrote: > Shahram, > =20 > This was my concern excatly. We can not force BFd packet to follow a = specific link, and it may happen that LAG receives and trasmits from = diffrent links. To make this matter even harder these links can live on = diffrerent card, if it is a cross-card LAG. If we want to use BFD for = link-oam then lets call it something else and that is 802.3 ah and 802.3 = ag. 802.3 ag can support sub-second timers I believe. Even then if there = is motivation/use-case to have per-link BFD lets keep it saprate rom BFD = as a client of IP. > =20 > Thanks > Jagrati=20 >=20 > On Sat, Jul 30, 2011 at 5:53 AM, Shahram Davari = wrote: > Hi >=20 > Each layer should have its own OAM. You should not run OAM on other = layers as proxy for a different layer. This is architecturally wrong. >=20 > Since LAG hashing is not standard then how can you force a BFD packet = to follow a specific link? Should we now start terminating IP layer = before LAG layer? Why not just use 802.3ah or 802.1ag? >=20 > Consequences of layer violations are known. They can range from = security issues to standards that are not generic and run just under for = a specific application. >=20 > Regards > Shahram >=20 > ----- Original Message ----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, July 29, 2011 03:38 PM > To: Shahram Davari > Cc: 'manav.bhatia@alcatel-lucent.com' = ; 'rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hello Sharam, >=20 > sorry but could you please be more specific? "has consequences" means = what exactly for you? >=20 > The layering has a consequence on the sequence of bringing up LAG = links, BFD sessions etc. The draft is mentioning this. >=20 >=20 > Regards, Marc >=20 >=20 > On 2011-07-30, at 12:21 AM, Shahram Davari wrote: >=20 > > BFD is a client if IP layer and IP is a client of Ethernet. = Therefore BFD is technically above LAG and therefore can't be run for = individual LAG links. Doing anything else is not only a layer violation = but has consequences. > > > > Thx > > Shahram > > > > ----- Original Message ----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Friday, July 29, 2011 03:03 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-bfd@ietf.org > > Subject: Re: Solicit comments on BFD for Interface draft > > > > Hello Manav, > > > > others have already replied but the part "[...] has no business" = triggers now my reply. I deliberately "mis"-understand it. Point is that = this is about business. Customers have pushed their vendors to implement = BFD over LAG component links. Reasons I know > > > > - LACP is not fast enough > > - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers = and Operations, so they would like to use it everywhere > > - BFDs reputation for being fast and working > > > > > > So now we have 3-4 different implementation for per-cmponent-link = BFD that I know about. Potentially there exists more. Probably not that = much different but enough to make interoperability impossible. It's = again customers who push now for standardization. Thus the draft to find = an agreement :-) > > > > Will there be only one solution for "BFD over LAG"? Not sure as I = see two fundamental setups: (a) run BFD on every component link and (b) = run a single BFD session over the LAG interface. They solve different = network setups as far as I can see. > > > > > > Regards, Marc > > > > > > > > On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: > > > >> Hi Jeff, > >> > >> Let me understand this. If you have an IP interface over a LAG with = 5 component links, then you internally establish 5 BFD sessions with = 30ms timeouts? > >> > >> You don't need to do this. You could use LACP for lag and BFD for = IP connectivity - which means BFD should remain up as long as there is = reachability over the lag. IMO it has no business to bother with each = individual component links. > >> > >> Cheers, Manav > >> > >> -----Original Message----- > >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > >> Sent: Friday, July 29, 2011 7:15 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Mach Chen; rtg-bfd@ietf.org > >> Subject: Re: Solicit comments on BFD for Interface draft > >> > >> Hi, > >> > >> We have been supporting this mode of BFD over LAG operations for = last 5 years and our customers love it. > >> > >> Manav - imagine you have lost 3 out of 8 links but didn't hit = min-links, do you really want to bring the LAG down? > >> > >> Mach - be aware of patents :) > >> > >> Regards, > >> Jeff > >> > >> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" = wrote: > >> > >>> Hi Mach, > >>> > >>> I am not sure I understand why you would want BFD to ensure = liveliness of each component link in a LAG. The draft seems to suggest = establishing separate BFD session for each pair of component interfaces = to detect the failures. Why should BFD be concerned about each component = link? I would rather that BFD sprays packets over each component link in = a round robin fashion and brings down the IP interface over a lag only = if it misses 3 consecutive packets. Am I missing something? > >>> > >>> Cheers, Manav > >>> > >>> -----Original Message----- > >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] = On > >>> Behalf Of Mach Chen > >>> Sent: Friday, July 29, 2011 4:05 AM > >>> To: rtg-bfd@ietf.org > >>> Subject: Solicit comments on BFD for Interface draft > >>> > >>> Hi, > >>> > >>> We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. > >>> > >>> Many thanks, > >>> Mach > >> > > > > -- > > Marc Binderberger > > > > > > >=20 > -- > Marc Binderberger >=20 >=20 >=20 >=20 -- Marc Binderberger --Apple-Mail-2-854744939 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Jagrati,

your first points seem to be more an = implementation discussion, not a principal problem as at least 3 teams = have managed to overcome the issues you = mention.

We are not competing against LACP = here. We are offering a different solution, thus we name it BFD and not = 802.3-something and propose it on the IETF BFD list.
I admit = using it instead/in parallel to LACP is what some implementations are = doing and what the authors documented with section 4 as an example. But = we are not restricted to this scenario. What is does is providing = information from another layer into "BFD". Whatever you make out of the = information (*).

Could it be done with = BFD-over-Ethernet frames? Probably. I first thought into this direction = myself. The relevant point is it turned out we don't have to and can = stick to what we and customers know: BFD using IP/UDP. =  


Regards, = Marc

(*: maybe we have to define this = "whatever" for interoperability. Discussion will show = :-)



On 2011-07-30, = at 4:31 AM, Jagrati Shringi wrote:

Shahram,
 
This was my concern excatly. We can not force BFd packet to follow = a specific link, and it may happen that LAG receives and trasmits from = diffrent links. To make this matter even harder these links can live on = diffrerent card, if it is a cross-card LAG. If we want to use BFD for = link-oam then lets call it something else and that is 802.3 ah and 802.3 = ag. 802.3 ag can support sub-second timers I believe. Even then if there = is motivation/use-case to have per-link BFD lets keep it saprate rom BFD = as a client of IP.
 
Thanks
Jagrati 

On Sat, Jul 30, 2011 at 5:53 AM, Shahram = Davari <davari@broadcom.com> wrote:
Hi

Each layer = should have its own OAM. You should not run OAM on other layers as proxy = for a different layer. This is architecturally wrong.

Since LAG hashing is not standard then how can you force a BFD = packet to follow a specific link? Should we now start terminating IP = layer before LAG layer? Why not just use 802.3ah or = 802.1ag?

Consequences of layer violations are known. They can = range from security issues to standards that are not generic and run = just under for a specific application.

Regards
Shahram

----- Original Message -----
From: Marc = Binderberger [mailto:marc@sniff.de]
Sent: Friday, July 29, 2011 03:38 PM
To: Shahram Davari
Cc: = 'manav.bhatia@alcatel-lucent.com' <manav.bhatia@alcatel-lucent.com>; 'rtg-bfd@ietf.org' = <rtg-bfd@ietf.org>
Subject: Re: Solicit comments on BFD for Interface draft

Hello = Sharam,

sorry but could you please be more specific? "has = consequences" means what exactly for you?

The layering has a = consequence on the sequence of bringing up LAG links, BFD sessions etc. = The draft is mentioning this.


Regards, Marc


On 2011-07-30, at 12:21 AM, Shahram = Davari wrote:

> BFD is a client if IP layer and IP is a client = of Ethernet. Therefore BFD is technically above LAG and therefore can't = be run for individual LAG links. Doing anything else is not only a layer = violation but has consequences.
>
> Thx
> Shahram
>
> ----- Original Message = -----
> From: Marc Binderberger [mailto:marc@sniff.de]
>= Sent: Friday, July 29, 2011 03:03 PM
> To: Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com>
> Cc: rtg-bfd@ietf.org = <rtg-bfd@ietf.org>
> Subject: Re: Solicit comments on BFD for Interface = draft
>
> Hello Manav,
>
> others have already = replied but the part "[...] has no business" triggers now my reply. I = deliberately "mis"-understand it. Point is that this is about business. = Customers have pushed their vendors to implement BFD over LAG component = links. Reasons I know
>
> - LACP is not fast enough
> - BFD in it's IP form = (IP+UDP+BFD) is understood by Telco Designers and Operations, so they = would like to use it everywhere
> - BFDs reputation for being fast = and working
>
>
> So now we have 3-4 different implementation for = per-cmponent-link BFD that I know about. Potentially there exists more. = Probably not that much different but enough to make interoperability = impossible. It's again customers who push now for standardization. Thus = the draft to find an agreement :-)
>
> Will there be only one solution for "BFD over LAG"? Not = sure as I see two fundamental setups: (a) run BFD on every component = link  and (b) run a single BFD session over the LAG interface. They = solve different network setups as far as I can see.
>
>
> Regards, Marc
>
>
>
> On = 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote:
>
>> = Hi Jeff,
>>
>> Let me understand this. If you have an = IP interface over a LAG with 5 component links, then you internally = establish 5 BFD sessions with 30ms timeouts?
>>
>> You don't need to do this. You could use LACP for = lag and BFD for IP connectivity - which means BFD should remain up as = long as there is reachability over the lag. IMO it has no business to = bother with each individual component links.
>>
>> Cheers, Manav
>>
>> -----Original = Message-----
>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]
>> Sent: Friday, July 29, 2011 7:15 AM
>> To: Bhatia, = Manav (Manav)
>> Cc: Mach Chen; rtg-bfd@ietf.org
>> Subject: Re: Solicit = comments on BFD for Interface draft
>>
>> Hi,
>>
>> We have been supporting = this mode of BFD over LAG operations for last 5 years and our customers = love it.
>>
>> Manav - imagine you have lost 3 out of = 8 links but didn't hit min-links, do you really want to bring the LAG = down?
>>
>> Mach - be aware of patents = :)
>>
>> Regards,
>> = Jeff
>>
>> On Jul 28, 2011, at 21:25, "Bhatia, Manav = (Manav)" <manav.bhatia@alcatel-lucent.com> wrote:
>>
>>> Hi Mach,
>>>
>>> I am = not sure I understand why you would want BFD to ensure liveliness of = each component link in a LAG. The draft seems to suggest establishing = separate BFD session for each pair of component interfaces to detect the = failures. Why should BFD be concerned about each component link? I would = rather that BFD sprays packets over each component link in a round robin = fashion and brings down the IP interface over a lag only if it misses 3 = consecutive packets. Am I missing something?
>>>
>>> Cheers, = Manav
>>>
>>> -----Original = Message-----
>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
>>> Behalf Of Mach Chen
>>> Sent: Friday, July 29, = 2011 4:05 AM
>>> To: rtg-bfd@ietf.org
>>> Subject: Solicit = comments on BFD for Interface draft
>>>
>>> Hi,
>>>
>>> We = uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD running over interface(e.g., LAG/Bundle = interface). You are very welcome to read the draft and give your = comments.
>>>
>>> Many thanks,
>>> = Mach
>>
>
> --
> Marc Binderberger   =         <marc@sniff.de>
>
>
>

--
Marc Binderberger           = <marc@sniff.de>





--
marc@sniff.de>

= --Apple-Mail-2-854744939-- From marc@sniff.de Sat Jul 30 05:03:06 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDDD21F8A6C for ; Sat, 30 Jul 2011 05:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW1aC4daLZUd for ; Sat, 30 Jul 2011 05:03:06 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id A966721F8A51 for ; Sat, 30 Jul 2011 05:03:05 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 872BA2AA0F; Sat, 30 Jul 2011 12:02:34 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 30 Jul 2011 14:02:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78DFBA91-99BF-43A5-8110-6CCCAD1DD265@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 12:03:06 -0000 Hello Manav! > I think the diagnoses is correct, but the medicine isn't! :-) well, it's a different medicine we propose, not necessarily a wrong one = ;-) > Are we trying to position BFD as an IETF equivalent of 802.1ag? No > Or is it that we're trying to run BFD over component links since not = all links may be ethernet? Actually we do have POS-based bundles (but not mixed POS/Ethernet) on = our equipment. So IP is the natural common layer for both, POS and = Ethernet. The draft is not talking about it but focuses on the more = tricky one, which is Ethernet and it's MAC filter on the receiving side.=20= > Shouldn't BFD be oblivious to the number of links alive in a LAG as = long as the LAG remains up and it can reach the other end. Reaching the other end with BFD is not an achievement on it's own :-) Lets look at the round-robin BFD. A single component link failure has = not impact on BFD, unless the Multiplier is 1. But depending on your LAG = load-balance either several flows have 100% loss (flow-based) or every = flow has a loss of 1/M (round-robin, with M: number of component links). So BFD is kind of useless in this case. And once the LAG is declared = down by LACP you have this information already in your OS (and I guess = we all have mechanism to react immediately to Intf downs). > It is a simple implementation effort to note the status of each = component link of a lag and to bring it down if the number goes below a = certain threshold - You don't need to run BFD over each link! I beg to differ :-) Actually from the discussion above one can ask what _is_ the gain we = have from single-BFD through a LAG? For sure not a detection of a = (local) LAG problem, it fails to provide a gain as showed above. Regards, Marc >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de]=20 >> Sent: Saturday, July 30, 2011 3:34 AM >> To: Bhatia, Manav (Manav) >> Cc: Jeff Tantsura; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hello Manav, >>=20 >> others have already replied but the part "[...] has no=20 >> business" triggers now my reply. I deliberately=20 >> "mis"-understand it. Point is that this is about business.=20 >> Customers have pushed their vendors to implement BFD over LAG=20 >> component links. Reasons I know >>=20 >> - LACP is not fast enough >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >> Designers and Operations, so they would like to use it everywhere >> - BFDs reputation for being fast and working >>=20 >>=20 >> So now we have 3-4 different implementation for=20 >> per-cmponent-link BFD that I know about. Potentially there=20 >> exists more. Probably not that much different but enough to=20 >> make interoperability impossible. It's again customers who=20 >> push now for standardization. Thus the draft to find an agreement :-) >>=20 >> Will there be only one solution for "BFD over LAG"? Not sure=20 >> as I see two fundamental setups: (a) run BFD on every=20 >> component link and (b) run a single BFD session over the LAG=20 >> interface. They solve different network setups as far as I can see. >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Jeff, >>>=20 >>> Let me understand this. If you have an IP interface over a=20 >> LAG with 5 component links, then you internally establish 5=20 >> BFD sessions with 30ms timeouts? >>>=20 >>> You don't need to do this. You could use LACP for lag and=20 >> BFD for IP connectivity - which means BFD should remain up as=20 >> long as there is reachability over the lag. IMO it has no=20 >> business to bother with each individual component links.=20 >>>=20 >>> Cheers, Manav >>>=20 >>> -----Original Message----- >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>> Sent: Friday, July 29, 2011 7:15 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Mach Chen; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hi, >>>=20 >>> We have been supporting this mode of BFD over LAG=20 >> operations for last 5 years and our customers love it. >>>=20 >>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >> hit min-links, do you really want to bring the LAG down? >>>=20 >>> Mach - be aware of patents :) >>>=20 >>> Regards, >>> Jeff >>>=20 >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >> wrote: >>>=20 >>>> Hi Mach, >>>>=20 >>>> I am not sure I understand why you would want BFD to=20 >> ensure liveliness of each component link in a LAG. The draft=20 >> seems to suggest establishing separate BFD session for each=20 >> pair of component interfaces to detect the failures. Why=20 >> should BFD be concerned about each component link? I would=20 >> rather that BFD sprays packets over each component link in a=20 >> round robin fashion and brings down the IP interface over a=20 >> lag only if it misses 3 consecutive packets. Am I missing something? >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org=20 >> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>> Behalf Of Mach Chen >>>> Sent: Friday, July 29, 2011 4:05 AM >>>> To: rtg-bfd@ietf.org >>>> Subject: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We uploaded a new=20 >> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >> that is about BFD running over interface(e.g., LAG/Bundle=20 >> interface). You are very welcome to read the draft and give=20 >> your comments. >>>>=20 >>>> Many thanks, >>>> Mach >>>=20 >>=20 >> -- >> Marc Binderberger >>=20 >>=20 -- Marc Binderberger From manav.bhatia@alcatel-lucent.com Sat Jul 30 06:10:47 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590EF21F8A91 for ; Sat, 30 Jul 2011 06:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9zW2H5f+nAD for ; Sat, 30 Jul 2011 06:10:46 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 801BE21F8A95 for ; Sat, 30 Jul 2011 06:10:45 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6UDAdSw007309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jul 2011 08:10:42 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6UDAbOl004237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Jul 2011 18:40:38 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 30 Jul 2011 18:40:37 +0530 From: "Bhatia, Manav (Manav)" To: Marc Binderberger Date: Sat, 30 Jul 2011 18:40:36 +0530 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxOsJdepHpe3txWTaCZnPO0UiPJOQACPIXQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF56D6C2@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <78DFBA91-99BF-43A5-8110-6CCCAD1DD265@sniff.de> In-Reply-To: <78DFBA91-99BF-43A5-8110-6CCCAD1DD265@sniff.de> 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-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 13:10:47 -0000 Hi Marc, > Reaching the other end with BFD is not an achievement on it's=20 > own :-) Lets look at the round-robin BFD. A single component=20 > link failure has not impact on BFD, unless the Multiplier is=20 > 1. But depending on your LAG load-balance either several=20 > flows have 100% loss (flow-based) or every flow has a loss of=20 > 1/M (round-robin, with M: number of component links). > So BFD is kind of useless in this case. And once the LAG is=20 > declared down by LACP you have this information already in=20 > your OS (and I guess we all have mechanism to react=20 > immediately to Intf downs). Why cant we use eth-cfm (or other OAM utilities) to detect the loss of comp= onent links in the LAG? Does BFD offer a benefit over other OAM protocols t= hat are meant to monitor link liveliness? Cheers, Manav= From shane@castlepoint.net Sat Jul 30 09:36:28 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E62121F889A for ; Sat, 30 Jul 2011 09:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj7oUS5HEeYy for ; Sat, 30 Jul 2011 09:36:27 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55421F8892 for ; Sat, 30 Jul 2011 09:36:27 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 29936268037; Sat, 30 Jul 2011 10:36:28 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sat, 30 Jul 2011 10:36:27 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=50725; syn-fingerprint=65535:54:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 30 Jul 2011 10:36:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2011 16:36:28 -0000 Manav, Sharam, Others, On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: > I think the diagnoses is correct, but the medicine isn't! :-) >=20 > I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 = (or 802.3ah) for *fast* detection of component-link failures in a LAG = is: operational simplicity, clear and simple. The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how = many variables are *required* to properly set-up 802.1ag/Y.1731: a) What MD "name" should you use? b) What MD "name format" should you use, (ASCII, DNS, etc.)? c) What MD "level" should you use, (probably 0 or 1)? d) What MEP ID's do I assign to each side of the link? e) Don't forget to configure the right direction, up or down, for the = MEP? ... that is *ridiculous*! Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and = over and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex = to set-up *and* maintain. =20 BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx} = interval". (The "multiplier" should default to 3, unless you want to = configure it differently). That's it! Done! So, in short, let me throw my hat in the ring with other operators that = I really, really, really want a standards-based way of running BFD over = component-links in a LAG in order to quickly detect a component-link = failure and take it out of the bundle. Thanks, -shane > I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de]=20 >> Sent: Saturday, July 30, 2011 3:34 AM >> To: Bhatia, Manav (Manav) >> Cc: Jeff Tantsura; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hello Manav, >>=20 >> others have already replied but the part "[...] has no=20 >> business" triggers now my reply. I deliberately=20 >> "mis"-understand it. Point is that this is about business.=20 >> Customers have pushed their vendors to implement BFD over LAG=20 >> component links. Reasons I know >>=20 >> - LACP is not fast enough >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >> Designers and Operations, so they would like to use it everywhere >> - BFDs reputation for being fast and working >>=20 >>=20 >> So now we have 3-4 different implementation for=20 >> per-cmponent-link BFD that I know about. Potentially there=20 >> exists more. Probably not that much different but enough to=20 >> make interoperability impossible. It's again customers who=20 >> push now for standardization. Thus the draft to find an agreement :-) >>=20 >> Will there be only one solution for "BFD over LAG"? Not sure=20 >> as I see two fundamental setups: (a) run BFD on every=20 >> component link and (b) run a single BFD session over the LAG=20 >> interface. They solve different network setups as far as I can see. >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Jeff, >>>=20 >>> Let me understand this. If you have an IP interface over a=20 >> LAG with 5 component links, then you internally establish 5=20 >> BFD sessions with 30ms timeouts? >>>=20 >>> You don't need to do this. You could use LACP for lag and=20 >> BFD for IP connectivity - which means BFD should remain up as=20 >> long as there is reachability over the lag. IMO it has no=20 >> business to bother with each individual component links.=20 >>>=20 >>> Cheers, Manav >>>=20 >>> -----Original Message----- >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>> Sent: Friday, July 29, 2011 7:15 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Mach Chen; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hi, >>>=20 >>> We have been supporting this mode of BFD over LAG=20 >> operations for last 5 years and our customers love it. >>>=20 >>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >> hit min-links, do you really want to bring the LAG down? >>>=20 >>> Mach - be aware of patents :) >>>=20 >>> Regards, >>> Jeff >>>=20 >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >> wrote: >>>=20 >>>> Hi Mach, >>>>=20 >>>> I am not sure I understand why you would want BFD to=20 >> ensure liveliness of each component link in a LAG. The draft=20 >> seems to suggest establishing separate BFD session for each=20 >> pair of component interfaces to detect the failures. Why=20 >> should BFD be concerned about each component link? I would=20 >> rather that BFD sprays packets over each component link in a=20 >> round robin fashion and brings down the IP interface over a=20 >> lag only if it misses 3 consecutive packets. Am I missing something? >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org=20 >> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>> Behalf Of Mach Chen >>>> Sent: Friday, July 29, 2011 4:05 AM >>>> To: rtg-bfd@ietf.org >>>> Subject: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We uploaded a new=20 >> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >> that is about BFD running over interface(e.g., LAG/Bundle=20 >> interface). You are very welcome to read the draft and give=20 >> your comments. >>>>=20 >>>> Many thanks, >>>> Mach >>>=20 >>=20 >> -- >> Marc Binderberger >>=20 >>=20 From Alexander.Vainshtein@ecitele.com Sun Jul 31 05:41:44 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A573D21F8753 for ; Sun, 31 Jul 2011 05:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ5H+uxwA5xi for ; Sun, 31 Jul 2011 05:41:40 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id E9F9F21F8747 for ; Sun, 31 Jul 2011 05:41:39 -0700 (PDT) X-AuditID: 93eaf2e7-b7c81ae000000c7e-7d-4e35359bbeae Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D5.A8.03198.B95353E4; Sun, 31 Jul 2011 13:59:39 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 31 Jul 2011 13:59:45 +0300 From: Alexander Vainshtein To: Jagrati Shringi Date: Sun, 31 Jul 2011 13:59:44 +0300 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxN4D3BVeSgzl3YRZWlU3tffm/HHwBjvxRA Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <654701C60BCC7C4EBD533B89D72BDFEA053F36C9@XMB-RCD-204.cisco.com> <24FF88BE62B5394C83AC8BA2828C9F9B0488AA43@XMB-BGL-415.cisco.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: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76EC603474F1ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTe2xLURzHnXvv2rvZ5a7W7az8UdcrQVnXVbpYZSFLZtjmLRKPu/ZoL+29 TW+3qAQNETQTDBsTtjGyGGEj4v2YEOpNIgtG2LzqFZtUzKPu3d1miTh/fc/v9/n9vr+cnB+J a3ardSTH+5CXZ12MKo7YFm77athtNuelhuvSLGXXQ4TlUe06taX950lgaV8bUGcROdt/1Mfk nK5oVufU1HzHCvD5AZDJ8rzgY31Ib0eizcoUeLli1uZn9JzdyhgZvcfF2pAb8T4rw3o8iLcz E+L0/5xMCeN4PeJtgp3jHVZm8sx8g8VizjAYmQnDhxhN4+NmOTlRjwxulnPp3UgUWQfSS5HF J3Dn7Vf31Z6OvWD5uZI9WABUB0EQkCSk0+GlRjYIYiWZBO89O6oKgjhSQ18EsK70B6FcygA8 9vItLlMq2gob6ppVsk6kR8DSquO4DOH0BgCjZ27GyAmCHgYb7jzvhAbQFnjsSUtXQQY8vims kp0T6TQYvLBSDlN0Pqw/H+oyCxDwzutgZ59Yejp8tL+yUwNpvG+hw5iscToZPm6txJSxaVhz 7i6uaC181/K7i9fCp+uPAoUX4Ml3HwnFLAHe2NVKKHwKvFzbRGwBSRW92lb0KqnoVaLER8Oq s20qRY+CB6vf49361qUWrHe8CqgPAS3n8vgK3Y5U4xhk43zIhcbYBHcDUH7Tm1Ogo3JoI6BJ wMRTzkh6niaGLRb97kaQQmKMloJGc56mX6Fg9ztZ0bnIW+RCYiOAJM4kUq1XTXkays76VyCv 0J3Kll5/K67raxOkf8v7FplSU/9/YZKpV7YP0zS0Q/qcyxDyIG93n0EkyUBqTZpkn+BFDrR8 Cefy/U1jZKw8Rrw0RrbMUKKHdYucQ8mHgIH8WXLlKtAQvMAjXTJVJkO0DDmL+J4+8k6tjkaj YZAsPcAAKiBT8dLG9XQKSyaYZDKvI102kZaoJ6ULgK3Fdz99mVv3Qnvq8YzVC2flLpgztrxp emGkIKbUvTPTnJI7cvPOlQW5k9sG70tovfj6oGnqpIdLD6wt2dGvtulsJNqe0rz+c6g8qzRx 9nDToSOrijAie1wx8yCim7hFGJvpz335cUr/X7eCG+EgPztJO7Cmvs+qIk8kiejofy0rbduQ DIYQnaxxJO4V2T9Zh51OLgQAAA== Cc: "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 12:41:44 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76EC603474F1ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Jagrati and all, Quoting from IEEE 802.3-2005 Part 5, Section 57.1.2: a) Remote Failure Indication 1) A mechanism is provided to indicate to a peer that the receive path of th= e local DTE is nonoperational. 2) Physical layer devices using Clause 66 may support unidirectional operati= on that allows OAM remote failure indication during fault conditions. 3) Subscriber access physical layer devices using Clause 65 support unidirec= tional operation in the direction from OLT to ONU that allows OAM remote failure indication from= OLT during fault conditions. 4) Physical layer devices other than those listed above do not support unidi= rectional operation allowing OAM remote failure indication during fault conditions. Some physica= l layer devices have specific remote failure signaling mechanisms in the physical layer. In other words, certain Ethernet media do not support unidirectional operati= on, i.e., if they co not receive a valid signal (as in the case of LOS) they= cannot transmit an LACP packet to a peer. And of course some dedia types do not propagate failures properly. E.g., con= ider a an Ethernet link that uses a repeater in the middle... Regards, Sasha From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Jagrati Shringi Sent: Friday, July 29, 2011 2:11 PM To: Ankush Arora (anarora) Cc: Reshad Rahman (rrahman); rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Long LACP timers are relevant for non-receipt of packet, But on seeing a LoS= LACP can notify the peer of a failure. It does not have to wait for Second= timers to do so. Per link BFD mkes more sense on media where getting LoS is= not guranteed. Also per link BFD should not be confused probably with BFD o= ver LAG. Mach, so I am assuming per link BFD session will continue to live o= n forwardign plane. Will there will be a aggregation on control plane? As li= nk of the LAG can be spread across multiple forwarding planes. Thanks Jagrati On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (anarora) > wrote: Yes that's true. Since LACP doesn't support sub-second intervals, that is th= e primary reason, customers like the BFD over each member link feature. Consider a scenario where you have 4 links in a bundle and min links is not= configured or configured for 2 links. If the third link goes down, so the bundle stays up and will be used. If you spray one packet over each link, then you will never have 3 consecuti= ve packet failures and BFD will never detect this. LACP would detect this, but you cant have sub-second failure detection to re= move the 3rd link. Even if you had min links =3D max for LACP, for the bundle to be brought dow= n, you will have to depend on LACP timers. Regards, Ankush This e-mail may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply e= -mail and delete all copies of this message. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Reshad R= ahman (rrahman) Sent: Thursday, July 28, 2011 10:25 PM To: Bhatia, Manav (Manav); Jeff Tantsura Cc: rtg-bfd@ietf.org Subject: RE: Solicit comments on BFD for Interface draft Hi, I don't think LACP supports sub-second intervals. Also there might be failures which BFD could detect but which LACP doesn't? A bit of a layering violation but if the interface is L3 only... Regards, Reshad. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) Sent: Thursday, July 28, 2011 10:18 PM To: Jeff Tantsura Cc: rtg-bfd@ietf.org Subject: RE: Solicit comments on BFD for Interface draft Hi Jeff, Let me understand this. If you have an IP interface over a LAG with 5 component links, then you internally establish 5 BFD sessions with 30ms timeouts? You don't need to do this. You could use LACP for lag and BFD for IP connectivity - which means BFD should remain up as long as there is reachability over the lag. IMO it has no business to bother with each individual component links. Cheers, Manav -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] Sent: Friday, July 29, 2011 7:15 AM To: Bhatia, Manav (Manav) Cc: Mach Chen; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Hi, We have been supporting this mode of BFD over LAG operations for last 5 years and our customers love it. Manav - imagine you have lost 3 out of 8 links but didn't hit min-links, do you really want to bring the LAG down? Mach - be aware of patents :) Regards, Jeff On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" > wr= ote: > Hi Mach, > > I am not sure I understand why you would want BFD to ensure liveliness of each component link in a LAG. The draft seems to suggest establishing separate BFD session for each pair of component interfaces to detect the failures. Why should BFD be concerned about each component link? I would rather that BFD sprays packets over each component link in a round robin fashion and brings down the IP interface over a lag only if it misses 3 consecutive packets. Am I missing something? > > Cheers, Manav > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rt= g-bfd-bounces@ietf.org] On > Behalf Of Mach Chen > Sent: Friday, July 29, 2011 4:05 AM > To: rtg-bfd@ietf.org > Subject: Solicit comments on BFD for Interface draft > > Hi, > > We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD running over interface(e.g., LAG/Bundle interface). You are very welcome to read the draft and give your comments. > > Many thanks, > Mach This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76EC603474F1ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Jagrati and= all,

Quoting from IEEE 802.3-2005 Part 5, Section 57.1.2:=

 

a) Remote Failure I= ndication

1) A mechanism is provided to indicate to a= peer that the receive path of the local DTE is nonoperational.

2) Physical layer devices using Clause 66 may support unidirectio= nal operation that allows OAM

remote failure indicat= ion during fault conditions.

3) Subscriber access phy= sical layer devices using Clause 65 support unidirectional operation in=

the direction from OLT to ONU that allows OAM remote fail= ure indication from OLT during

fault conditions.=

4) Physical layer devices other than those listed above d= o not support unidirectional operation

allowing OAM r= emote failure indication during fault conditions. Some physical layer device= s

have specific remote failure signaling mechanisms in the physical layer= .

 

In other words, certain= Ethernet media do not support unidirectional operation, i.e., if they co no= t receive a valid signal (as in the case of LOS) they cannot transmit an LAC= P packet to a peer.

&nb= sp;

And of course some dedia type= s do not propagate failures properly. E.g., conider a an Ethernet link that= uses a repeater in the middle…

 

Regards,

     Sasha=

 

From: rtg-bfd-bounces@ietf.org [mailto= :rtg-bfd-bounces@ietf.org] On Behalf Of Jagrati Shringi
Sent: Friday, July 29, 2011 2:11 PM
To: Ankush Arora (anarora)
= Cc: Reshad Rahman (rrahman); rtg-bfd@ietf.org
Subject: Re: Sol= icit comments on BFD for Interface draft

 

 

Long LACP timers are relevant for= non-receipt of packet, But on seeing a LoS LACP can notify the peer of a fa= ilure. It does not have to wait for Second timers to do so. Per link BFD mke= s more sense on media where getting LoS is not guranteed. Also per link BFD= should not be confused probably with BFD over LAG. Mach, so I am assuming p= er link BFD session will continue to live on forwardign plane. Will there wi= ll be a aggregation on control plane? As link of the LAG can be spread acros= s multiple forwarding planes. 

 

Thanks=

Jagrati

On Fri, Jul 29, 2011 at 8:14 AM= , Ankush Arora (anarora) <anarora@ci= sco.com> wrote:

Yes that's true. S= ince LACP doesn't support sub-second intervals, that is the primary reason,= customers like the BFD over each member link feature.

Consider a sce= nario where you have 4 links in a bundle and min links is not configured or= configured for 2 links.
If the third link goes down, so the bundle stays= up and will be used.
If you spray one packet over each link, then you wi= ll never have 3 consecutive packet failures and BFD will never detect this.<= br>LACP would detect this, but you cant have sub-second failure detection to= remove the 3rd link.
Even if you had min links =3D max for LACP, for the= bundle to be brought down, you will have to depend on LACP timers.

<= br>Regards,
Ankush


This e-mail may contain confidential and pr= ivileged material for the sole use of the intended recipient. Any review, us= e, distribution or disclosure by others is strictly prohibited. If you are n= ot the intended recipient (or authorized to receive for the recipient), plea= se contact the sender by reply e-mail and delete all copies of this message.=   


-----Original= Message-----
From: rtg-bfd-b= ounces@ietf.org [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Reshad Rahman (rrahman)
Sent: Thur= sday, July 28, 2011 10:25 PM
To: Bhatia, Manav (Manav); Jeff Tantsura
= Cc: rtg-bfd@ietf.org
Subject: RE:= Solicit comments on BFD for Interface draft

Hi,

I don't think= LACP supports sub-second intervals. Also there might be
failures which B= FD could detect but which LACP doesn't?  A bit of a
layering violati= on but if the interface is L3 only...

Regards,
Reshad.

----= -Original Message-----
From: = rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
Behalf Of Bhatia, Manav (Manav)
= Sent: Thursday, July 28, 2011 10:18 PM
To: Jeff Tantsura
Cc: rtg-bfd@ietf.org
Subject: RE: Solicit co= mments on BFD for Interface draft

Hi Jeff,

Let me understand t= his. If you have an IP interface over a LAG with 5
component links, then= you internally establish 5 BFD sessions with 30ms
timeouts?

You d= on't need to do this. You could use LACP for lag and BFD for IP
connectiv= ity - which means BFD should remain up as long as there is
reachability o= ver the lag. IMO it has no business to bother with each
individual compon= ent links.

Cheers, Manav

-----Original Message-----
From: J= eff Tantsura [mailto:jeff.tant= sura@ericsson.com]
Sent: Friday, July 29, 2011 7:15 AM
To: Bhatia,= Manav (Manav)
Cc: Mach Chen; rtg-bfd= @ietf.org
Subject: Re: Solicit comments on BFD for Interface draft
Hi,

We have been supporting this mode of BFD over LAG operations= for last 5
years and our customers love it.

Manav - imagine you h= ave lost 3 out of 8 links but didn't hit min-links,
do you really want to= bring the LAG down?

Mach - be aware of patents :)

Regards,Jeff

On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"<manav.bhatia@alcatel= -lucent.com> wrote:

> Hi Mach,
>
> I am not sur= e I understand why you would want BFD to ensure liveliness
of each compon= ent link in a LAG. The draft seems to suggest establishing
separate BFD s= ession for each pair of component interfaces to detect the
failures. Why= should BFD be concerned about each component link? I would
rather that B= FD sprays packets over each component link in a round robin
fashion and b= rings down the IP interface over a lag only if it misses 3
consecutive pa= ckets. Am I missing something?
>
> Cheers, Manav
>
>= -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> Behalf Of Mach Chen<= br>> Sent: Friday, July 29, 2011 4:05 AM
> To: rtg-bfd@ietf.org
> Subject: Solicit comments on BF= D for Interface draft
>
> Hi,
>
> We uploaded a new<= br>draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is
about BFD running over interface(e.g., LAG/Bundle interface).= You are
very welcome to read the draft and give your comments.
>> Many thanks,
> Mach

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76EC603474F1ILPTMAIL02eci_-- From davari@broadcom.com Sun Jul 31 07:43:52 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C12A21F8747 for ; Sun, 31 Jul 2011 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDipEy7Sxgq0 for ; Sun, 31 Jul 2011 07:43:51 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3931621F85A7 for ; Sun, 31 Jul 2011 07:43:51 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 31 Jul 2011 07:48:42 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Sun, 31 Jul 2011 07:43:44 -0700 From: "Shahram Davari" To: "Shane Amante" , "Bhatia, Manav (Manav)" Date: Sun, 31 Jul 2011 07:43:45 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxO1t0m5poCSGwaTIWWfg/NMcXCCQAuFuvQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622BB4C03KO1200520-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 14:43:52 -0000 Hi Shane, Same for BFD. You need to know my discriminator, your discriminator, local = IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand mod= e, Authentication, Active/Passive, Detection Interval, etc. Believe me BFD requires more configuration than 802.1ag. So your argument o= f requiring a lot of info to configure 802.1ag applies even more to BFD.=20 Regards Shahram =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shane Amante Sent: Saturday, July 30, 2011 9:36 AM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Manav, Sharam, Others, On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: > I think the diagnoses is correct, but the medicine isn't! :-) >=20 > I completely agree that LACP is not fast enough and that operators also w= ant to detect individual component link breakdowns instead of the entire LA= G. If that's the case then folks should use IEEE 802.1ag for individual com= ponent links and BFD for the entire LAG. Are we trying to position BFD as a= n IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over co= mponent links since not all links may be ethernet? The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 (o= r 802.3ah) for *fast* detection of component-link failures in a LAG is: ope= rational simplicity, clear and simple. The problem with 802.1ag/Y.1731 is the massive amount of, potentially error= -prone, configuration required. Take a moment and think about how many var= iables are *required* to properly set-up 802.1ag/Y.1731: a) What MD "name" should you use? b) What MD "name format" should you use, (ASCII, DNS, etc.)? c) What MD "level" should you use, (probably 0 or 1)? d) What MEP ID's do I assign to each side of the link? e) Don't forget to configure the right direction, up or down, for the MEP? ... that is *ridiculous*! Let's not forget that there are [potentially] 100's if not 1,000's of LAG's= in each carrier's network, so this needs to get repeated over and over and= over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up *a= nd* maintain. =20 BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx} in= terval". (The "multiplier" should default to 3, unless you want to configu= re it differently). That's it! Done! So, in short, let me throw my hat in the ring with other operators that I r= eally, really, really want a standards-based way of running BFD over compon= ent-links in a LAG in order to quickly detect a component-link failure and = take it out of the bundle. Thanks, -shane > I think (and this is also what Shahram was alluding to) that BFD is meant= to detect IP liveliness. This means that if I run BFD over an IP interface= it should bring it down only when the IP connectivity goes down. Shouldn't= BFD be oblivious to the number of links alive in a LAG as long as the LAG = remains up and it can reach the other end. It is a simple implementation ef= fort to note the status of each component link of a lag and to bring it dow= n if the number goes below a certain threshold - You don't need to run BFD = over each link! >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de]=20 >> Sent: Saturday, July 30, 2011 3:34 AM >> To: Bhatia, Manav (Manav) >> Cc: Jeff Tantsura; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hello Manav, >>=20 >> others have already replied but the part "[...] has no=20 >> business" triggers now my reply. I deliberately=20 >> "mis"-understand it. Point is that this is about business.=20 >> Customers have pushed their vendors to implement BFD over LAG=20 >> component links. Reasons I know >>=20 >> - LACP is not fast enough >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >> Designers and Operations, so they would like to use it everywhere >> - BFDs reputation for being fast and working >>=20 >>=20 >> So now we have 3-4 different implementation for=20 >> per-cmponent-link BFD that I know about. Potentially there=20 >> exists more. Probably not that much different but enough to=20 >> make interoperability impossible. It's again customers who=20 >> push now for standardization. Thus the draft to find an agreement :-) >>=20 >> Will there be only one solution for "BFD over LAG"? Not sure=20 >> as I see two fundamental setups: (a) run BFD on every=20 >> component link and (b) run a single BFD session over the LAG=20 >> interface. They solve different network setups as far as I can see. >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Jeff, >>>=20 >>> Let me understand this. If you have an IP interface over a=20 >> LAG with 5 component links, then you internally establish 5=20 >> BFD sessions with 30ms timeouts? >>>=20 >>> You don't need to do this. You could use LACP for lag and=20 >> BFD for IP connectivity - which means BFD should remain up as=20 >> long as there is reachability over the lag. IMO it has no=20 >> business to bother with each individual component links.=20 >>>=20 >>> Cheers, Manav >>>=20 >>> -----Original Message----- >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>> Sent: Friday, July 29, 2011 7:15 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Mach Chen; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hi, >>>=20 >>> We have been supporting this mode of BFD over LAG=20 >> operations for last 5 years and our customers love it. >>>=20 >>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >> hit min-links, do you really want to bring the LAG down? >>>=20 >>> Mach - be aware of patents :) >>>=20 >>> Regards, >>> Jeff >>>=20 >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >> wrote: >>>=20 >>>> Hi Mach, >>>>=20 >>>> I am not sure I understand why you would want BFD to=20 >> ensure liveliness of each component link in a LAG. The draft=20 >> seems to suggest establishing separate BFD session for each=20 >> pair of component interfaces to detect the failures. Why=20 >> should BFD be concerned about each component link? I would=20 >> rather that BFD sprays packets over each component link in a=20 >> round robin fashion and brings down the IP interface over a=20 >> lag only if it misses 3 consecutive packets. Am I missing something? >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org=20 >> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>> Behalf Of Mach Chen >>>> Sent: Friday, July 29, 2011 4:05 AM >>>> To: rtg-bfd@ietf.org >>>> Subject: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We uploaded a new=20 >> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >> that is about BFD running over interface(e.g., LAG/Bundle=20 >> interface). You are very welcome to read the draft and give=20 >> your comments. >>>>=20 >>>> Many thanks, >>>> Mach >>>=20 >>=20 >> -- >> Marc Binderberger >>=20 >>=20 From Alexander.Vainshtein@ecitele.com Sun Jul 31 07:54:54 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4E521F86D7 for ; Sun, 31 Jul 2011 07:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vegi4o+RUpoK for ; Sun, 31 Jul 2011 07:54:53 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 198CB21F86C4 for ; Sun, 31 Jul 2011 07:54:52 -0700 (PDT) X-AuditID: 93eaf2e8-b7ce7ae000000a69-0d-4e3565f2cce9 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 14.14.02665.2F5653E4; Sun, 31 Jul 2011 17:25:54 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sun, 31 Jul 2011 17:54:47 +0300 From: Alexander Vainshtein To: Shahram Davari , Shane Amante , "Bhatia, Manav (Manav)" Date: Sun, 31 Jul 2011 17:54:42 +0300 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxO1t0m5poCSGwaTIWWfg/NMcXCCQAuFuvQAABMCQA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.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="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLJsWRmVeSWpSXmKPExsUy+dWnL7qfUk39DK4tFrVY3+tpMefePVaL z3+2MVo8P3yQyYHFo/XZXlaPWffPsnn8/TeT3WPJkp9MASxRDYw2iXl5+SWJJakKKanFybZK AUWZZYnJlUoKmSm2SoZKCgU5icmpual5JbZKiQUFqXkpSnZcChjABqgsM08hNS85PyUzL91W yTPYX9fCwtRS11DJTk3Z0NiaKyQjs1ghVTc3MTNHITe1uDgxPVUBKJKwhTljZ8sn9oIJLhXz F5xiaWA8ZtrFyMkhIWAiMe/LTiYIW0ziwr31bF2MXBxCAjsZJXY3vWSGcKYwSmxd+54FpIpN wFZi0+q7YFUiAr2MEr2nQBxODmYBTYmmE5/ZQWwWAVWJyQung40VFrCQ2HD7MViNiIClxObe V1C2lcTsY1MYQWxeAX+JWStegNlCAodYJCbsB+vlFIiSeLN1B1g9I9B530+tYYLYJS5x68l8 qLMFJJbsOc8MYYtKvHz8jxWiXlTiTvt6Roh6HYkFuz9B3aktsWzha2aIvYISJ2c+YYHolZQ4 uOIGywRG8VlIVsxC0j4LSfssJO0LGFlWMUpm5hSUJOWmGxjp5peW6KUmZ5ak5qTqJefnbmKE JJ4XOxhvn9E8xCjAwajEw7tTwMRPiDWxrLgy9xCjJAeTkigvQ46pnxBfUn5KZUZicUZ8UWlO avEhRgkOZiUR3idHjf2EeFMSK6tSi/JhUhbAkJ7ILMWdnA9Mpnkl8cYGBigcJXHe7uQ3vkIC 6cCkl52aWpBaBNMqw8GhJME7LR5oo2BRanpqRVpmTglCmomDE2QzD9BmRpCreIsLEnOLM9Mh 8qcYdTn+9Bw+yijEkpeflyolzusLUiQAUpRRmgc3B5Rr6v////+KURzoZ2Fea5AqHmCegpv0 CmgJE9CSiF8mIEuAWQQuJdXAKHywk7/tqli7r4n0w7uLZ9maZa0OtWi4f/nWN0OukIhb66Oc 6n7//L105YLAp0f6VU1evdWwW/zvf3Jm+gmBBfF8qTnfv5xb3S31Jlx+Rcvp++pMn380aPrP 2REx7zBvY+Dxm98MpZkzfzUcvJysaPhvu73DrdVP+rapc9RMLEpdOl0q5m7QOyWW4oxEQy3m ouJEAH61lY4QBAAA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 14:54:54 -0000 Shahram, I disagree with you - please see some detailed comments inline below. Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf= Of > Shahram Davari > Sent: Sunday, July 31, 2011 5:44 PM > To: Shane Amante; Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: Solicit comments on BFD for Interface draft > > Hi Shane, > > Same for BFD. You need to know: > my discriminator [[Sasha]] Automatically allocated, no need to configure > your discriminator[[[Sasha]]] You learn it - please see RFC 5880 for the d= etails > local IP address, [[[Sasha]]] You usually configure it anyway in an IP wor= ld > remote IP address[[[Sasha]]] You learn it from IGP, or configure it in an= y case in the case of ISBR > Min Tx Interval, Min Rx Interval, [[[Sasha]]] Yes you have to configure it= - Shane has indicated that > Demand mode [[Sasha]] You do not have to configure it > Authentication [[Sasha]] You may configure it if you want to use it, the d= efault presumably is none. With 802.1ag you simply do not have this function= ality, so you cannot use it even if you wish >Active/Passive, [[[Sasha]]] Defaults to Active > Detection Interval [[Sasha]] If you mean the detect multiplier, it default= s to 3. > > Believe me BFD requires more configuration than 802.1ag. So your argument= of > requiring a lot of info to configure 802.1ag applies even more to BFD. > [[[Sasha]]] Sorry I do not believe you. > Regards > Shahram > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf= Of > Shane Amante > Sent: Saturday, July 30, 2011 9:36 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft > > Manav, Sharam, Others, > > On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: > > I think the diagnoses is correct, but the medicine isn't! :-) > > > > I completely agree that LACP is not fast enough and that operators also= want > to detect individual component link breakdowns instead of the entire LAG.= If > that's the case then folks should use IEEE 802.1ag for individual componen= t > links and BFD for the entire LAG. Are we trying to position BFD as an IETF > equivalent of 802.1ag? Or is it that we're trying to run BFD over componen= t > links since not all links may be ethernet? > > The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 (= or > 802.3ah) for *fast* detection of component-link failures in a LAG is: > operational simplicity, clear and simple. > > The problem with 802.1ag/Y.1731 is the massive amount of, potentially erro= r- > prone, configuration required. Take a moment and think about how many > variables are *required* to properly set-up 802.1ag/Y.1731: > a) What MD "name" should you use? > b) What MD "name format" should you use, (ASCII, DNS, etc.)? > c) What MD "level" should you use, (probably 0 or 1)? > d) What MEP ID's do I assign to each side of the link? > e) Don't forget to configure the right direction, up or down, for the MEP= ? > ... that is *ridiculous*! > > Let's not forget that there are [potentially] 100's if not 1,000's of LAG'= s in > each carrier's network, so this needs to get repeated over and over and ov= er > again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up *and* > maintain. > > BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx} > interval". (The "multiplier" should default to 3, unless you want to > configure it differently). That's it! Done! > > So, in short, let me throw my hat in the ring with other operators that I > really, really, really want a standards-based way of running BFD over > component-links in a LAG in order to quickly detect a component-link failu= re > and take it out of the bundle. > > Thanks, > > -shane > > > > > I think (and this is also what Shahram was alluding to) that BFD is mean= t to > detect IP liveliness. This means that if I run BFD over an IP interface it > should bring it down only when the IP connectivity goes down. Shouldn't BF= D be > oblivious to the number of links alive in a LAG as long as the LAG remains= up > and it can reach the other end. It is a simple implementation effort to no= te > the status of each component link of a lag and to bring it down if the num= ber > goes below a certain threshold - You don't need to run BFD over each link! > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Saturday, July 30, 2011 3:34 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Jeff Tantsura; rtg-bfd@ietf.org > >> Subject: Re: Solicit comments on BFD for Interface draft > >> > >> Hello Manav, > >> > >> others have already replied but the part "[...] has no > >> business" triggers now my reply. I deliberately > >> "mis"-understand it. Point is that this is about business. > >> Customers have pushed their vendors to implement BFD over LAG > >> component links. Reasons I know > >> > >> - LACP is not fast enough > >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco > >> Designers and Operations, so they would like to use it everywhere > >> - BFDs reputation for being fast and working > >> > >> > >> So now we have 3-4 different implementation for > >> per-cmponent-link BFD that I know about. Potentially there > >> exists more. Probably not that much different but enough to > >> make interoperability impossible. It's again customers who > >> push now for standardization. Thus the draft to find an agreement :-) > >> > >> Will there be only one solution for "BFD over LAG"? Not sure > >> as I see two fundamental setups: (a) run BFD on every > >> component link and (b) run a single BFD session over the LAG > >> interface. They solve different network setups as far as I can see. > >> > >> > >> Regards, Marc > >> > >> > >> > >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: > >> > >>> Hi Jeff, > >>> > >>> Let me understand this. If you have an IP interface over a > >> LAG with 5 component links, then you internally establish 5 > >> BFD sessions with 30ms timeouts? > >>> > >>> You don't need to do this. You could use LACP for lag and > >> BFD for IP connectivity - which means BFD should remain up as > >> long as there is reachability over the lag. IMO it has no > >> business to bother with each individual component links. > >>> > >>> Cheers, Manav > >>> > >>> -----Original Message----- > >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > >>> Sent: Friday, July 29, 2011 7:15 AM > >>> To: Bhatia, Manav (Manav) > >>> Cc: Mach Chen; rtg-bfd@ietf.org > >>> Subject: Re: Solicit comments on BFD for Interface draft > >>> > >>> Hi, > >>> > >>> We have been supporting this mode of BFD over LAG > >> operations for last 5 years and our customers love it. > >>> > >>> Manav - imagine you have lost 3 out of 8 links but didn't > >> hit min-links, do you really want to bring the LAG down? > >>> > >>> Mach - be aware of patents :) > >>> > >>> Regards, > >>> Jeff > >>> > >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" > >> wrote: > >>> > >>>> Hi Mach, > >>>> > >>>> I am not sure I understand why you would want BFD to > >> ensure liveliness of each component link in a LAG. The draft > >> seems to suggest establishing separate BFD session for each > >> pair of component interfaces to detect the failures. Why > >> should BFD be concerned about each component link? I would > >> rather that BFD sprays packets over each component link in a > >> round robin fashion and brings down the IP interface over a > >> lag only if it misses 3 consecutive packets. Am I missing something? > >>>> > >>>> Cheers, Manav > >>>> > >>>> -----Original Message----- > >>>> From: rtg-bfd-bounces@ietf.org > >> [mailto:rtg-bfd-bounces@ietf.org] On > >>>> Behalf Of Mach Chen > >>>> Sent: Friday, July 29, 2011 4:05 AM > >>>> To: rtg-bfd@ietf.org > >>>> Subject: Solicit comments on BFD for Interface draft > >>>> > >>>> Hi, > >>>> > >>>> We uploaded a new > >> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) > >> that is about BFD running over interface(e.g., LAG/Bundle > >> interface). You are very welcome to read the draft and give > >> your comments. > >>>> > >>>> Many thanks, > >>>> Mach > >>> > >> > >> -- > >> Marc Binderberger > >> > >> > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From davari@broadcom.com Sun Jul 31 08:06:28 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8121F87F9 for ; Sun, 31 Jul 2011 08:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxPQAEJ7peDx for ; Sun, 31 Jul 2011 08:06:27 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAB121F87ED for ; Sun, 31 Jul 2011 08:06:27 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 31 Jul 2011 08:11:16 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 31 Jul 2011 08:06:18 -0700 From: "Shahram Davari" To: "Marc Binderberger" Date: Sun, 31 Jul 2011 08:06:17 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxOkxr17wjZVSiZQ16uq3hSx51lcwA/ZtXw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93261641F@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266C@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622BAF1E3KO1205961-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 15:06:28 -0000 Hi Marc, I was pointing out a general rule of protocol design. I think we in the IET= F or any standard organization should strive to follow such rules unless th= ere is no other easy solution. In this case there is also already a solutio= n which is 802.ag. Your argument is not valid that we need a single protoco= l to do Link as well as IP layer OAM, since if you continue this path soone= r or later one could ask why not run BFD for Ethernet and why not run BFD f= or OTN and why not run BFD for GPON. Anyways I will try to provide some specific technical reasons why running B= FD for Link is not a good idea; 1) From protocol layering, where should IP layer be? Do we need 1 IP layer = or 2 IP layers now? Since we would need BFD termination before and after LA= G termination? 2) What happens if the other end is not configured to terminate the Multica= st address that you want? Then it will be sent to the network? 3) how do you force a BFD packet to take a specific link? 4) How do I differentiate between BFD packets if they are sent to a central= processor for processing? Thx Shahram -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Saturday, July 30, 2011 1:31 AM To: Shahram Davari Cc: 'manav.bhatia@alcatel-lucent.com'; 'rtg-bfd@ietf.org' Subject: Re: Solicit comments on BFD for Interface draft Hello Sharam, second time you make generic statements but avoid concrete details. I'm sor= ry to say it but this is not the way to run a discussion. I do appreciate your warning about layer violation. I fully respect your pe= rsonal style of designing and am interested to learn from you. But establis= hing a dogma in a technical discussion doesn't make sense. The last paragraphs of section 2 and 3 pick the topic of layer violation up= , we only don't name it this way but focus on the result. If you think this= needs more attention in the text - I'm open to constructive comments. That= 's why we are here on the list I think :-) Thanks & Regards, Marc On 2011-07-30, at 2:23 AM, Shahram Davari wrote: > Hi >=20 > Each layer should have its own OAM. You should not run OAM on other layer= s as proxy for a different layer. This is architecturally wrong.=20 >=20 > Since LAG hashing is not standard then how can you force a BFD packet to = follow a specific link? Should we now start terminating IP layer before LAG= layer? Why not just use 802.3ah or 802.1ag? >=20 > Consequences of layer violations are known. They can range from security = issues to standards that are not generic and run just under for a specific = application. >=20 > Regards > Shahram >=20 > ----- Original Message ----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, July 29, 2011 03:38 PM > To: Shahram Davari > Cc: 'manav.bhatia@alcatel-lucent.com' ; = 'rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hello Sharam, >=20 > sorry but could you please be more specific? "has consequences" means wha= t exactly for you? >=20 > The layering has a consequence on the sequence of bringing up LAG links, = BFD sessions etc. The draft is mentioning this. >=20 >=20 > Regards, Marc >=20 >=20 > On 2011-07-30, at 12:21 AM, Shahram Davari wrote: >=20 >> BFD is a client if IP layer and IP is a client of Ethernet. Therefore BF= D is technically above LAG and therefore can't be run for individual LAG li= nks. Doing anything else is not only a layer violation but has consequences= . >>=20 >> Thx >> Shahram >>=20 >> ----- Original Message ----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Friday, July 29, 2011 03:03 PM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hello Manav, >>=20 >> others have already replied but the part "[...] has no business" trigger= s now my reply. I deliberately "mis"-understand it. Point is that this is a= bout business. Customers have pushed their vendors to implement BFD over LA= G component links. Reasons I know >>=20 >> - LACP is not fast enough >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers and = Operations, so they would like to use it everywhere >> - BFDs reputation for being fast and working >>=20 >>=20 >> So now we have 3-4 different implementation for per-cmponent-link BFD th= at I know about. Potentially there exists more. Probably not that much diff= erent but enough to make interoperability impossible. It's again customers = who push now for standardization. Thus the draft to find an agreement :-) >>=20 >> Will there be only one solution for "BFD over LAG"? Not sure as I see tw= o fundamental setups: (a) run BFD on every component link and (b) run a si= ngle BFD session over the LAG interface. They solve different network setup= s as far as I can see. >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Jeff, >>>=20 >>> Let me understand this. If you have an IP interface over a LAG with 5 c= omponent links, then you internally establish 5 BFD sessions with 30ms time= outs? >>>=20 >>> You don't need to do this. You could use LACP for lag and BFD for IP co= nnectivity - which means BFD should remain up as long as there is reachabil= ity over the lag. IMO it has no business to bother with each individual com= ponent links.=20 >>>=20 >>> Cheers, Manav >>>=20 >>> -----Original Message----- >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 >>> Sent: Friday, July 29, 2011 7:15 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Mach Chen; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hi, >>>=20 >>> We have been supporting this mode of BFD over LAG operations for last 5= years and our customers love it. >>>=20 >>> Manav - imagine you have lost 3 out of 8 links but didn't hit min-links= , do you really want to bring the LAG down? >>>=20 >>> Mach - be aware of patents :) >>>=20 >>> Regards, >>> Jeff >>>=20 >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" wrote: >>>=20 >>>> Hi Mach, >>>>=20 >>>> I am not sure I understand why you would want BFD to ensure liveliness= of each component link in a LAG. The draft seems to suggest establishing s= eparate BFD session for each pair of component interfaces to detect the fai= lures. Why should BFD be concerned about each component link? I would rathe= r that BFD sprays packets over each component link in a round robin fashion= and brings down the IP interface over a lag only if it misses 3 consecutiv= e packets. Am I missing something? >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>> Behalf Of Mach Chen >>>> Sent: Friday, July 29, 2011 4:05 AM >>>> To: rtg-bfd@ietf.org >>>> Subject: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-inte= rface-00) that is about BFD running over interface(e.g., LAG/Bundle interfa= ce). You are very welcome to read the draft and give your comments. >>>>=20 >>>> Many thanks, >>>> Mach >>>=20 >>=20 >> -- >> Marc Binderberger >>=20 >>=20 >>=20 >=20 > -- > Marc Binderberger >=20 >=20 >=20 -- Marc Binderberger From Alexander.Vainshtein@ecitele.com Sun Jul 31 09:17:55 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3519821F84F6 for ; Sun, 31 Jul 2011 09:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF4GiGOr5dA3 for ; Sun, 31 Jul 2011 09:17:54 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8C99B21F84F5 for ; Sun, 31 Jul 2011 09:17:53 -0700 (PDT) X-AuditID: 93eaf2e8-b7ce7ae000000a69-e8-4e35796e12cc Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id EC.84.02665.E69753E4; Sun, 31 Jul 2011 18:49:02 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sun, 31 Jul 2011 19:17:55 +0300 From: Alexander Vainshtein To: Shahram Davari Date: Sun, 31 Jul 2011 19:17:54 +0300 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxO1t0m5poCSGwaTIWWfg/NMcXCCQAuFuvQAABMCQAAAwlTGQ== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com>, <02D7222D58419F409B1BE84E6095C260C03C4F756B@ILPTMAIL02.ecitele.com> In-Reply-To: <02D7222D58419F409B1BE84E6095C260C03C4F756B@ILPTMAIL02.ecitele.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="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0zTUBiGc9oyy6CmDHEHIrpUMN6GQy5OYcZoTOCHA6OJxES0dsetsnVz LciMymKChnkP+sPFRFS8k2BQjET9ASjxGq8YFYUEFpFJVEBDVBRbi4ixv95z3vc7zznN95G4 rl+TQPKChLwC62Q0WqIy3P/ZKPgyrKYbT5LMtXtzzQNDV4C5u7kRW4TnBDseaHJ+/DwyLqe6 +iuWj6/2g2xWENwSKyGDDYmchcn38iUs52MMvM3CpDIGj5PlkAsJkoVhPR4k2JiFWsN/X7Yc 4wUDEji3jRfsFiZ3RZ7RbM6Yb0xlFk6bmpqWpV3p4EUDMrpY3mlwIVFk7cgg76y7jDu+hE9g nlBu6b72APAD/4IAiCQhnQ7Pdf/AVD0RPmqv1QSAltTRDQAO3fgUoS4OAVh+59jvlIa2wLoL bzSKnkBPh42vnuGKxunlsPVQFxEAJEnQybB/QKdsx9JmeLGtayQ+H17aGx7Ri2GL/y1QNEXn weazIUxl7YyAL++9GKcYkXQ+bO1pIBQN5NsN3q3BVJYevgodG7k1DauvP8RVHQd7un5GqPk4 +HpXLVDzs2HVtX6NqmfB08ff4yo4Bt45EiLU2njYePYFcQDog2MQwTHlwTHlwTHlVYA4D+J5 p0da77Kb5hrdxVIK4ngJOVEK53bVAbVj3l0FbfdnNAGaBEw01UCnW3URbInoczWBeBJj4qjN ZRlW3fj1bpvPwYqOtd5iJxKbACRxZgJ1rUT2KBvr24K87j+WWf7TB/GEKM4t96YgrU0zmf5Z MHpqN9e7TEfb5c4rQsiDvH9KJ5EkA6lShRjjRXZUuoF3Sn9tjIxUyNEyOUvJUKKHdYm8XfXv AiM5tKf5FtARgltACXrKqoRoJeQoFkbPUUalbHh4OAz08ptjqe5SORUtD9LoSWEZgsmQgm/p CkSekFErwQ+SZh419VbGVczZfjLqVMzQUlvdQE594cal2QcyY25pJjdsHVyWnFixJaWlddOH juR5z4umLK5pCvQWEudvDhYsSim/3Vfj2WbNLDt8vzA2cYnpySTfiozaZ5Uns1ZlA++a+uDT 053F38/0fWwJPU7D9Ten7qgiB7WvG0vsydsW7O/kYhlCdLCpM3GvyP4CwnK9TQUEAAA= Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 16:17:55 -0000 Shahram, and all, When I said (in the previous email) that I do not believe you, I only had in= mind your statement about the BFD configuration burden. I apologize if this= has been misunderstood. IMHO and FWIW, the difference between BFD and 802.1ag when it comes to confi= guration is that with BFD the user has only to configure the things that are= needed anyway (with or without BFD) and a few parameters of the BFD session= . To the best of my understanding this is not the case in 802.1ag. Regards, Sasha ________________________________________ From: Alexander Vainshtein Sent: Sunday, July 31, 2011 5:54 PM To: Shahram Davari; Shane Amante; Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: RE: Solicit comments on BFD for Interface draft Shahram, I disagree with you - please see some detailed comments inline below. Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf= Of > Shahram Davari > Sent: Sunday, July 31, 2011 5:44 PM > To: Shane Amante; Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: Solicit comments on BFD for Interface draft > > Hi Shane, > > Same for BFD. You need to know: > my discriminator [[Sasha]] Automatically allocated, no need to configure > your discriminator[[[Sasha]]] You learn it - please see RFC 5880 for the d= etails > local IP address, [[[Sasha]]] You usually configure it anyway in an IP wor= ld > remote IP address[[[Sasha]]] You learn it from IGP, or configure it in an= y case in the case of ISBR > Min Tx Interval, Min Rx Interval, [[[Sasha]]] Yes you have to configure it= - Shane has indicated that > Demand mode [[Sasha]] You do not have to configure it > Authentication [[Sasha]] You may configure it if you want to use it, the d= efault presumably is none. With 802.1ag you simply do not have this function= ality, so you cannot use it even if you wish >Active/Passive, [[[Sasha]]] Defaults to Active > Detection Interval [[Sasha]] If you mean the detect multiplier, it default= s to 3. > > Believe me BFD requires more configuration than 802.1ag. So your argument= of > requiring a lot of info to configure 802.1ag applies even more to BFD. > [[[Sasha]]] Sorry I do not believe you. > Regards > Shahram > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf= Of > Shane Amante > Sent: Saturday, July 30, 2011 9:36 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft > > Manav, Sharam, Others, > > On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: > > I think the diagnoses is correct, but the medicine isn't! :-) > > > > I completely agree that LACP is not fast enough and that operators also= want > to detect individual component link breakdowns instead of the entire LAG.= If > that's the case then folks should use IEEE 802.1ag for individual componen= t > links and BFD for the entire LAG. Are we trying to position BFD as an IETF > equivalent of 802.1ag? Or is it that we're trying to run BFD over componen= t > links since not all links may be ethernet? > > The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 (= or > 802.3ah) for *fast* detection of component-link failures in a LAG is: > operational simplicity, clear and simple. > > The problem with 802.1ag/Y.1731 is the massive amount of, potentially erro= r- > prone, configuration required. Take a moment and think about how many > variables are *required* to properly set-up 802.1ag/Y.1731: > a) What MD "name" should you use? > b) What MD "name format" should you use, (ASCII, DNS, etc.)? > c) What MD "level" should you use, (probably 0 or 1)? > d) What MEP ID's do I assign to each side of the link? > e) Don't forget to configure the right direction, up or down, for the MEP= ? > ... that is *ridiculous*! > > Let's not forget that there are [potentially] 100's if not 1,000's of LAG'= s in > each carrier's network, so this needs to get repeated over and over and ov= er > again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up *and* > maintain. > > BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx} > interval". (The "multiplier" should default to 3, unless you want to > configure it differently). That's it! Done! > > So, in short, let me throw my hat in the ring with other operators that I > really, really, really want a standards-based way of running BFD over > component-links in a LAG in order to quickly detect a component-link failu= re > and take it out of the bundle. > > Thanks, > > -shane > > > > > I think (and this is also what Shahram was alluding to) that BFD is mean= t to > detect IP liveliness. This means that if I run BFD over an IP interface it > should bring it down only when the IP connectivity goes down. Shouldn't BF= D be > oblivious to the number of links alive in a LAG as long as the LAG remains= up > and it can reach the other end. It is a simple implementation effort to no= te > the status of each component link of a lag and to bring it down if the num= ber > goes below a certain threshold - You don't need to run BFD over each link! > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Saturday, July 30, 2011 3:34 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Jeff Tantsura; rtg-bfd@ietf.org > >> Subject: Re: Solicit comments on BFD for Interface draft > >> > >> Hello Manav, > >> > >> others have already replied but the part "[...] has no > >> business" triggers now my reply. I deliberately > >> "mis"-understand it. Point is that this is about business. > >> Customers have pushed their vendors to implement BFD over LAG > >> component links. Reasons I know > >> > >> - LACP is not fast enough > >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco > >> Designers and Operations, so they would like to use it everywhere > >> - BFDs reputation for being fast and working > >> > >> > >> So now we have 3-4 different implementation for > >> per-cmponent-link BFD that I know about. Potentially there > >> exists more. Probably not that much different but enough to > >> make interoperability impossible. It's again customers who > >> push now for standardization. Thus the draft to find an agreement :-) > >> > >> Will there be only one solution for "BFD over LAG"? Not sure > >> as I see two fundamental setups: (a) run BFD on every > >> component link and (b) run a single BFD session over the LAG > >> interface. They solve different network setups as far as I can see. > >> > >> > >> Regards, Marc > >> > >> > >> > >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: > >> > >>> Hi Jeff, > >>> > >>> Let me understand this. If you have an IP interface over a > >> LAG with 5 component links, then you internally establish 5 > >> BFD sessions with 30ms timeouts? > >>> > >>> You don't need to do this. You could use LACP for lag and > >> BFD for IP connectivity - which means BFD should remain up as > >> long as there is reachability over the lag. IMO it has no > >> business to bother with each individual component links. > >>> > >>> Cheers, Manav > >>> > >>> -----Original Message----- > >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > >>> Sent: Friday, July 29, 2011 7:15 AM > >>> To: Bhatia, Manav (Manav) > >>> Cc: Mach Chen; rtg-bfd@ietf.org > >>> Subject: Re: Solicit comments on BFD for Interface draft > >>> > >>> Hi, > >>> > >>> We have been supporting this mode of BFD over LAG > >> operations for last 5 years and our customers love it. > >>> > >>> Manav - imagine you have lost 3 out of 8 links but didn't > >> hit min-links, do you really want to bring the LAG down? > >>> > >>> Mach - be aware of patents :) > >>> > >>> Regards, > >>> Jeff > >>> > >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" > >> wrote: > >>> > >>>> Hi Mach, > >>>> > >>>> I am not sure I understand why you would want BFD to > >> ensure liveliness of each component link in a LAG. The draft > >> seems to suggest establishing separate BFD session for each > >> pair of component interfaces to detect the failures. Why > >> should BFD be concerned about each component link? I would > >> rather that BFD sprays packets over each component link in a > >> round robin fashion and brings down the IP interface over a > >> lag only if it misses 3 consecutive packets. Am I missing something? > >>>> > >>>> Cheers, Manav > >>>> > >>>> -----Original Message----- > >>>> From: rtg-bfd-bounces@ietf.org > >> [mailto:rtg-bfd-bounces@ietf.org] On > >>>> Behalf Of Mach Chen > >>>> Sent: Friday, July 29, 2011 4:05 AM > >>>> To: rtg-bfd@ietf.org > >>>> Subject: Solicit comments on BFD for Interface draft > >>>> > >>>> Hi, > >>>> > >>>> We uploaded a new > >> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) > >> that is about BFD running over interface(e.g., LAG/Bundle > >> interface). You are very welcome to read the draft and give > >> your comments. > >>>> > >>>> Many thanks, > >>>> Mach > >>> > >> > >> -- > >> Marc Binderberger > >> > >> > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From gregimirsky@gmail.com Sun Jul 31 14:33:27 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5619621F851A for ; Sun, 31 Jul 2011 14:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaINDm7L1-O8 for ; Sun, 31 Jul 2011 14:33:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2400621F8519 for ; Sun, 31 Jul 2011 14:33:26 -0700 (PDT) Received: by vxi40 with SMTP id 40so4834372vxi.31 for ; Sun, 31 Jul 2011 14:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KYjwev5Fl00lBA3qLyiPXj0lGqNWSovZBAGpkjvhmLU=; b=TTOiGkawyGGx4b+KFJkJYzyo45F224IezAgBn5y5sX5Q1wbi/Fn0m/J/dkLB7eP+IF V4jSa4xex8oxzxymlwvQacg9qdtCKEVxAw3A9ypEj1m8TU5f/ljVs+sy66RAabNBRS+V Fl3TRHkMP1vhWu2oowiaiImj5ECzw0bQaCqX0= MIME-Version: 1.0 Received: by 10.52.115.165 with SMTP id jp5mr3832928vdb.158.1312148008740; Sun, 31 Jul 2011 14:33:28 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Sun, 31 Jul 2011 14:33:28 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <02D7222D58419F409B1BE84E6095C260C03C4F756B@ILPTMAIL02.ecitele.com> Date: Sun, 31 Jul 2011 14:33:28 -0700 Message-ID: Subject: Re: Solicit comments on BFD for Interface draft From: Greg Mirsky To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 21:33:27 -0000 Dear Sasha, if to compare proposed BFD solution to any IEEE OAM, I'd look at 802.3ah, not 801.3ag. I think that such comparison might be valid. Then we'll find that there are fewer parameters required configuration for 802.3ah and not much more complex if compared with proposed solution. Regards, Greg On Sun, Jul 31, 2011 at 9:17 AM, Alexander Vainshtein wrote: > Shahram, and all, > When I said (in the previous email) that I do not believe you, I only had= in mind your statement about the BFD configuration burden. I apologize if = this has been misunderstood. > > IMHO and FWIW, the difference between BFD and 802.1ag when it comes to co= nfiguration is that with BFD the user has only to configure the things that= are needed anyway (with or without BFD) and a few parameters of the BFD se= ssion. To the best of my understanding this is not the case in 802.1ag. > > Regards, > =A0 =A0 Sasha > > ________________________________________ > From: Alexander Vainshtein > Sent: Sunday, July 31, 2011 5:54 PM > To: Shahram Davari; Shane Amante; Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: Solicit comments on BFD for Interface draft > > Shahram, > I disagree with you - please see some detailed comments inline below. > > Regards, > =A0 =A0 Sasha > > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beha= lf Of >> Shahram Davari >> Sent: Sunday, July 31, 2011 5:44 PM >> To: Shane Amante; Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: RE: Solicit comments on BFD for Interface draft >> >> Hi Shane, >> >> Same for BFD. You need to know: >> my discriminator [[Sasha]] Automatically allocated, no need to configure >> your discriminator[[[Sasha]]] You learn it - please see RFC 5880 for the= details >> local IP address, [[[Sasha]]] You usually configure it anyway in an IP w= orld >> remote IP address[[[Sasha]]] =A0You learn it from IGP, or configure it i= n any case in the case of ISBR >> Min Tx Interval, Min Rx Interval, [[[Sasha]]] Yes you have to configure = it - Shane has indicated that >> Demand mode [[Sasha]] You do not have to configure it >> Authentication [[Sasha]] You may configure it if you want to use it, the= default presumably is none. With 802.1ag you simply do not have this funct= ionality, so you cannot use it even if you wish >>Active/Passive, [[[Sasha]]] =A0Defaults to Active >> Detection Interval [[Sasha]] If you mean the detect multiplier, it defau= lts to 3. >> >> Believe me BFD requires more configuration than 802.1ag. So your argumen= t of >> requiring a lot of info to configure 802.1ag applies even more to BFD. >> > [[[Sasha]]] Sorry I do not believe you. > >> Regards >> Shahram >> >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beha= lf Of >> Shane Amante >> Sent: Saturday, July 30, 2011 9:36 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >> >> Manav, Sharam, Others, >> >> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >> > I think the diagnoses is correct, but the medicine isn't! :-) >> > >> > I completely agree that LACP is not fast enough and that operators als= o want >> to detect individual component link breakdowns instead of the entire LAG= . If >> that's the case then folks should use IEEE 802.1ag for individual compon= ent >> links and BFD for the entire LAG. Are we trying to position BFD as an IE= TF >> equivalent of 802.1ag? Or is it that we're trying to run BFD over compon= ent >> links since not all links may be ethernet? >> >> The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731= (or >> 802.3ah) for *fast* detection of component-link failures in a LAG is: >> operational simplicity, clear and simple. >> >> The problem with 802.1ag/Y.1731 is the massive amount of, potentially er= ror- >> prone, configuration required. =A0Take a moment and think about how many >> variables are *required* to properly set-up 802.1ag/Y.1731: >> a) =A0What MD "name" should you use? >> b) =A0What MD "name format" should you use, (ASCII, DNS, etc.)? >> c) =A0What MD "level" should you use, (probably 0 or 1)? >> d) =A0What MEP ID's do I assign to each side of the link? >> e) =A0Don't forget to configure the right direction, up or down, for the= MEP? >> ... that is *ridiculous*! >> >> Let's not forget that there are [potentially] 100's if not 1,000's of LA= G's in >> each carrier's network, so this needs to get repeated over and over and = over >> again. =A0Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up *an= d* >> maintain. >> >> BFD is simple. =A0At a bare minimum you just need to configure an "{Tx|R= x} >> interval". =A0(The "multiplier" should default to 3, unless you want to >> configure it differently). That's it! =A0Done! >> >> So, in short, let me throw my hat in the ring with other operators that = I >> really, really, really want a standards-based way of running BFD over >> component-links in a LAG in order to quickly detect a component-link fai= lure >> and take it out of the bundle. >> >> Thanks, >> >> -shane >> >> >> >> > I think (and this is also what Shahram was alluding to) that BFD is me= ant to >> detect IP liveliness. This means that if I run BFD over an IP interface = it >> should bring it down only when the IP connectivity goes down. Shouldn't = BFD be >> oblivious to the number of links alive in a LAG as long as the LAG remai= ns up >> and it can reach the other end. It is a simple implementation effort to = note >> the status of each component link of a lag and to bring it down if the n= umber >> goes below a certain threshold - You don't need to run BFD over each lin= k! >> > >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: Marc Binderberger [mailto:marc@sniff.de] >> >> Sent: Saturday, July 30, 2011 3:34 AM >> >> To: Bhatia, Manav (Manav) >> >> Cc: Jeff Tantsura; rtg-bfd@ietf.org >> >> Subject: Re: Solicit comments on BFD for Interface draft >> >> >> >> Hello Manav, >> >> >> >> others have already replied but the part "[...] has no >> >> business" triggers now my reply. I deliberately >> >> "mis"-understand it. Point is that this is about business. >> >> Customers have pushed their vendors to implement BFD over LAG >> >> component links. Reasons I know >> >> >> >> - LACP is not fast enough >> >> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >> >> Designers and Operations, so they would like to use it everywhere >> >> - BFDs reputation for being fast and working >> >> >> >> >> >> So now we have 3-4 different implementation for >> >> per-cmponent-link BFD that I know about. Potentially there >> >> exists more. Probably not that much different but enough to >> >> make interoperability impossible. It's again customers who >> >> push now for standardization. Thus the draft to find an agreement :-) >> >> >> >> Will there be only one solution for "BFD over LAG"? Not sure >> >> as I see two fundamental setups: (a) run BFD on every >> >> component link =A0and (b) run a single BFD session over the LAG >> >> interface. They solve different network setups as far as I can see. >> >> >> >> >> >> Regards, Marc >> >> >> >> >> >> >> >> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >> >> >> >>> Hi Jeff, >> >>> >> >>> Let me understand this. If you have an IP interface over a >> >> LAG with 5 component links, then you internally establish 5 >> >> BFD sessions with 30ms timeouts? >> >>> >> >>> You don't need to do this. You could use LACP for lag and >> >> BFD for IP connectivity - which means BFD should remain up as >> >> long as there is reachability over the lag. IMO it has no >> >> business to bother with each individual component links. >> >>> >> >>> Cheers, Manav >> >>> >> >>> -----Original Message----- >> >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >> >>> Sent: Friday, July 29, 2011 7:15 AM >> >>> To: Bhatia, Manav (Manav) >> >>> Cc: Mach Chen; rtg-bfd@ietf.org >> >>> Subject: Re: Solicit comments on BFD for Interface draft >> >>> >> >>> Hi, >> >>> >> >>> We have been supporting this mode of BFD over LAG >> >> operations for last 5 years and our customers love it. >> >>> >> >>> Manav - imagine you have lost 3 out of 8 links but didn't >> >> hit min-links, do you really want to bring the LAG down? >> >>> >> >>> Mach - be aware of patents :) >> >>> >> >>> Regards, >> >>> Jeff >> >>> >> >>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >> >> wrote: >> >>> >> >>>> Hi Mach, >> >>>> >> >>>> I am not sure I understand why you would want BFD to >> >> ensure liveliness of each component link in a LAG. The draft >> >> seems to suggest establishing separate BFD session for each >> >> pair of component interfaces to detect the failures. Why >> >> should BFD be concerned about each component link? I would >> >> rather that BFD sprays packets over each component link in a >> >> round robin fashion and brings down the IP interface over a >> >> lag only if it misses 3 consecutive packets. Am I missing something? >> >>>> >> >>>> Cheers, Manav >> >>>> >> >>>> -----Original Message----- >> >>>> From: rtg-bfd-bounces@ietf.org >> >> [mailto:rtg-bfd-bounces@ietf.org] On >> >>>> Behalf Of Mach Chen >> >>>> Sent: Friday, July 29, 2011 4:05 AM >> >>>> To: rtg-bfd@ietf.org >> >>>> Subject: Solicit comments on BFD for Interface draft >> >>>> >> >>>> Hi, >> >>>> >> >>>> We uploaded a new >> >> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >> >> that is about BFD running over interface(e.g., LAG/Bundle >> >> interface). You are very welcome to read the draft and give >> >> your comments. >> >>>> >> >>>> Many thanks, >> >>>> Mach >> >>> >> >> >> >> -- >> >> Marc Binderberger =A0 =A0 =A0 =A0 =A0 >> >> >> >> >> >> > > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > From shane@castlepoint.net Sun Jul 31 16:17:10 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F9F21F87D3 for ; Sun, 31 Jul 2011 16:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB9aYFBeElwI for ; Sun, 31 Jul 2011 16:17:09 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id AC1CB21F87BC for ; Sun, 31 Jul 2011 16:17:09 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 1399D268037; Sun, 31 Jul 2011 17:17:14 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 31 Jul 2011 17:17:13 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=58959; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> Date: Sun, 31 Jul 2011 17:16:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0B3ADE76-89AF-4C5E-B932-965C95A39220@castlepoint.net> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> To: Shahram Davari X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 23:17:10 -0000 Hi Sharam, On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: > Hi Shane, >=20 > Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, = Demand mode, Authentication, Active/Passive, Detection Interval, etc. As an _operator_ of BFD, I am not /required/ to configure every single = variable you named above, on every single link of every router in my = network. Good try though. =20 Not to pick on any one implementation, but here's proof that the only = required **configuration elements** necessary to bring up BFD was the = 'minimum-interval', (specifying a period of 100 msecs): ---snip--- interface fe-0/0/6.0 { point-to-point; bfd-liveness-detection { minimum-interval 100; } } [...] > show bfd session=20 Detect Transmit Address State Interface Time Interval = Multiplier 10.200.2.0 Up fe-0/0/6.0 0.300 0.100 = 3 =20 1 sessions, 1 clients Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps ---snip--- As with most IETF protocols, and particularly with smart & clever = implementers designing & coding them, very sensible defaults are chosen = so as to reduce the configuration burden on behalf of operators. This = is another way of saying, yes, as a [BFD] protocol implementer you need = to worry that you've implemented all of variables required by the RFC, = either by forcing the operator to give you input for them or, better = yet, by speaking to operators and choosing to implement sensible = defaults. > Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 The above would seem to indicate that's false. But, if you still don't = believe me, here's a short configuration snippet showing all of the = required configuration parameters to make IEEE 802.1ag work, on just a = single link: ---snip--- ethernet { connectivity-fault-management { maintenance-domain myOrg { level 1; name-format character-string; maintenance-association link-MA { short-name-format character-string; continuity-check { interval 100ms; } mep 2 { interface ge-3/0/1; direction down; remote-mep 5; } } } } } ---snip--- For starters, as an operator, good luck on trying to keep all your MEP = ID's straight for every component-link inside every LAG! And, again, = I'm not picking on any one vendor's configuration syntax ... the above = is no different, and sometimes worse, on any other vendor I've = configured 802.1ag/Y.1731. In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the = conclusion that the designers of those protocols were likely operating = under the assumption, at that time, that a OSS and/or NMS would be used = as the [sole] means to *configure* and *maintain* all of the = configuration elements required to bootstrap them and, when something = goes wrong, figure out what information is being reported by those = protocols. Unfortunately, this is completely *untrue* of how we run = IP/MPLS networks -- namely, we don't use NMS systems, particularly to = configure our networks!, and thus we need something simple, that just = works, i.e.: BFD. -shane >=20 > Regards > Shahram =20 >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante > Sent: Saturday, July 30, 2011 9:36 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Manav, Sharam, Others, >=20 > On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >> I think the diagnoses is correct, but the medicine isn't! :-) >>=20 >> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >=20 > The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >=20 > The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how = many variables are *required* to properly set-up 802.1ag/Y.1731: > a) What MD "name" should you use? > b) What MD "name format" should you use, (ASCII, DNS, etc.)? > c) What MD "level" should you use, (probably 0 or 1)? > d) What MEP ID's do I assign to each side of the link? > e) Don't forget to configure the right direction, up or down, for the = MEP? > ... that is *ridiculous*! >=20 > Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and = over and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex = to set-up *and* maintain. =20 >=20 > BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >=20 > So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 >> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>> Sent: Saturday, July 30, 2011 3:34 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hello Manav, >>>=20 >>> others have already replied but the part "[...] has no=20 >>> business" triggers now my reply. I deliberately=20 >>> "mis"-understand it. Point is that this is about business.=20 >>> Customers have pushed their vendors to implement BFD over LAG=20 >>> component links. Reasons I know >>>=20 >>> - LACP is not fast enough >>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>> Designers and Operations, so they would like to use it everywhere >>> - BFDs reputation for being fast and working >>>=20 >>>=20 >>> So now we have 3-4 different implementation for=20 >>> per-cmponent-link BFD that I know about. Potentially there=20 >>> exists more. Probably not that much different but enough to=20 >>> make interoperability impossible. It's again customers who=20 >>> push now for standardization. Thus the draft to find an agreement = :-) >>>=20 >>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>> as I see two fundamental setups: (a) run BFD on every=20 >>> component link and (b) run a single BFD session over the LAG=20 >>> interface. They solve different network setups as far as I can see. >>>=20 >>>=20 >>> Regards, Marc >>>=20 >>>=20 >>>=20 >>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>=20 >>>> Hi Jeff, >>>>=20 >>>> Let me understand this. If you have an IP interface over a=20 >>> LAG with 5 component links, then you internally establish 5=20 >>> BFD sessions with 30ms timeouts? >>>>=20 >>>> You don't need to do this. You could use LACP for lag and=20 >>> BFD for IP connectivity - which means BFD should remain up as=20 >>> long as there is reachability over the lag. IMO it has no=20 >>> business to bother with each individual component links.=20 >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>> Sent: Friday, July 29, 2011 7:15 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We have been supporting this mode of BFD over LAG=20 >>> operations for last 5 years and our customers love it. >>>>=20 >>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>> hit min-links, do you really want to bring the LAG down? >>>>=20 >>>> Mach - be aware of patents :) >>>>=20 >>>> Regards, >>>> Jeff >>>>=20 >>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>> wrote: >>>>=20 >>>>> Hi Mach, >>>>>=20 >>>>> I am not sure I understand why you would want BFD to=20 >>> ensure liveliness of each component link in a LAG. The draft=20 >>> seems to suggest establishing separate BFD session for each=20 >>> pair of component interfaces to detect the failures. Why=20 >>> should BFD be concerned about each component link? I would=20 >>> rather that BFD sprays packets over each component link in a=20 >>> round robin fashion and brings down the IP interface over a=20 >>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org=20 >>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>> Behalf Of Mach Chen >>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We uploaded a new=20 >>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>> interface). You are very welcome to read the draft and give=20 >>> your comments. >>>>>=20 >>>>> Many thanks, >>>>> Mach >>>>=20 >>>=20 >>> -- >>> Marc Binderberger >>>=20 >>>=20 >=20 >=20 >=20 From gregimirsky@gmail.com Sun Jul 31 16:59:54 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EC25E8002 for ; Sun, 31 Jul 2011 16:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcDVPaBqSfQX for ; Sun, 31 Jul 2011 16:59:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED815E8001 for ; Sun, 31 Jul 2011 16:59:54 -0700 (PDT) Received: by vxi40 with SMTP id 40so4884702vxi.31 for ; Sun, 31 Jul 2011 16:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=k0kY/IMGqNmy6B7ax8tplVJwSJe6AD2eOT2khOZF7aw=; b=VW1WZRi5R7khs/9sTkuFJZCdnpHQJzw0v6/ghoGo/XchmuXd3Kbe3Rg37k30acZkri nvjNyIqPJcfib5g1bvGVJYlbOCx9iTiCaOzYqJLJDUftejBtf6MAChNRU/C0Cm6n8pS6 PROPFf6xw5NBOW6boXnaNoCn+9ySQ9Bql0Sq4= MIME-Version: 1.0 Received: by 10.52.156.3 with SMTP id wa3mr4076334vdb.24.1312156797121; Sun, 31 Jul 2011 16:59:57 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Sun, 31 Jul 2011 16:59:57 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Jul 2011 16:59:57 -0700 Message-ID: Subject: Re: Solicit comments on BFD for Interface draft From: Greg Mirsky To: Mach Chen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2011 23:59:54 -0000 Dear Mach and All, please find my comments to the document below: =95 Introduction =93=85consequently taking down or bringing up the interfaces rapidly by BFD=94 I think that we don=92t want to react to every state change of a flapping interface. BFD should not be taking any actions but only report state change. Whether monitored object is activated or de-activated immediately or with dampened delay is outside of BFD scope. =95 Section 2 =93=85when the interface is itself the client of the BFD session, then the status of the interfaces will be associated with the status of the BFD session.=94 I=92d change the text to =93the status of the interface might be associated with the status of the BFD session=94. =95 Section 2 =93To avoid the deadlock BFD packets SHOULD NOT be blocked by the layer N protocol status of the interface when the application depends on the BFD status to enable layer N of the interface.=94 Wouldn=92t it be clearer to associate BFD session with Layer N-1 thus making it independent of state of Layer N? =95 Section 3. I think that when it will benefit the document to mention that the TTL MUST be set to 1. It might be obvious but would not hurt to make it explicit. =95 Section 4. From an implementation perspective it is usually better to react immediately to a Down event and delay or dampen Up to avoid flapping effect. =95 Section 5 I disagree that this document does not introduce any changes to RFC 5880 in regard to security. Making interface promiscuous to the new multicast address and allowing source address to be 0.0.0.0 clearly opens a new door for the DoS attacks. =95 I see as a limitation that the proposal depends on IP addressing, ability to process new multicast address. Thus the scope of the document, its applicability is limited to LAG interconnections between IP capable nodes. MPLS-TP, for example, doesn=92t have such limitation with use of G-ACh encapsulation. Kind regards, Greg On Thu, Jul 28, 2011 at 3:34 PM, Mach Chen wrote: > Hi, > > We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interfa= ce-00) that is about BFD running over interface(e.g., LAG/Bundle interface)= . You are very welcome to read the draft and give your comments. > > Many thanks, > Mach > From davari@broadcom.com Sun Jul 31 18:00:37 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1E221F883A for ; Sun, 31 Jul 2011 18:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE6eYo7+cLEE for ; Sun, 31 Jul 2011 18:00:36 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC505E8003 for ; Sun, 31 Jul 2011 18:00:36 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 31 Jul 2011 18:05:56 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 31 Jul 2011 18:00:22 -0700 From: "Shahram Davari" To: "'shane@castlepoint.net'" Date: Sun, 31 Jul 2011 18:00:21 -0700 Subject: Re: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxP2AXtHS+Wn/aOTz2QXtMUDHXRGQADl18G Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266E@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <0B3ADE76-89AF-4C5E-B932-965C95A39220@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622B247E3DK6425315-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 01:00:37 -0000 Hi shane Same can be said about ethernet oam. Basically everything can be automatica= lly assigned by software except MDL. As someone who has implemented OAM and BFD, I can certainly say BFD require= s more variables and parameters. Regards Shahram=20 Regards Shahram ----- Original Message ----- From: Shane Amante [mailto:shane@castlepoint.net] Sent: Sunday, July 31, 2011 04:16 PM=0A= To: Shahram Davari Cc: Bhatia, Manav (Manav) ; rtg-bfd@ietf.o= rg Subject: Re: Solicit comments on BFD for Interface draft Hi Sharam, On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: > Hi Shane, >=20 > Same for BFD. You need to know my discriminator, your discriminator, loca= l IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand m= ode, Authentication, Active/Passive, Detection Interval, etc. As an _operator_ of BFD, I am not /required/ to configure every single vari= able you named above, on every single link of every router in my network. = Good try though. =20 Not to pick on any one implementation, but here's proof that the only requi= red **configuration elements** necessary to bring up BFD was the 'minimum-i= nterval', (specifying a period of 100 msecs): ---snip--- interface fe-0/0/6.0 { point-to-point; bfd-liveness-detection { minimum-interval 100; } } [...] > show bfd session=20 Detect Transmit Address State Interface Time Interval Multip= lier 10.200.2.0 Up fe-0/0/6.0 0.300 0.100 3 = =20 1 sessions, 1 clients Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps ---snip--- As with most IETF protocols, and particularly with smart & clever implement= ers designing & coding them, very sensible defaults are chosen so as to red= uce the configuration burden on behalf of operators. This is another way o= f saying, yes, as a [BFD] protocol implementer you need to worry that you'v= e implemented all of variables required by the RFC, either by forcing the o= perator to give you input for them or, better yet, by speaking to operators= and choosing to implement sensible defaults. > Believe me BFD requires more configuration than 802.1ag. So your argument= of requiring a lot of info to configure 802.1ag applies even more to BFD.= =20 The above would seem to indicate that's false. But, if you still don't bel= ieve me, here's a short configuration snippet showing all of the required c= onfiguration parameters to make IEEE 802.1ag work, on just a single link: ---snip--- ethernet { connectivity-fault-management { maintenance-domain myOrg { level 1; name-format character-string; maintenance-association link-MA { short-name-format character-string; continuity-check { interval 100ms; } mep 2 { interface ge-3/0/1; direction down; remote-mep 5; } } } } } ---snip--- For starters, as an operator, good luck on trying to keep all your MEP ID's= straight for every component-link inside every LAG! And, again, I'm not p= icking on any one vendor's configuration syntax ... the above is no differe= nt, and sometimes worse, on any other vendor I've configured 802.1ag/Y.1731= . In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the concl= usion that the designers of those protocols were likely operating under the= assumption, at that time, that a OSS and/or NMS would be used as the [sole= ] means to *configure* and *maintain* all of the configuration elements req= uired to bootstrap them and, when something goes wrong, figure out what inf= ormation is being reported by those protocols. Unfortunately, this is comp= letely *untrue* of how we run IP/MPLS networks -- namely, we don't use NMS = systems, particularly to configure our networks!, and thus we need somethin= g simple, that just works, i.e.: BFD. -shane >=20 > Regards > Shahram =20 >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Shane Amante > Sent: Saturday, July 30, 2011 9:36 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Manav, Sharam, Others, >=20 > On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >> I think the diagnoses is correct, but the medicine isn't! :-) >>=20 >> I completely agree that LACP is not fast enough and that operators also = want to detect individual component link breakdowns instead of the entire L= AG. If that's the case then folks should use IEEE 802.1ag for individual co= mponent links and BFD for the entire LAG. Are we trying to position BFD as = an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over c= omponent links since not all links may be ethernet? >=20 > The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 = (or 802.3ah) for *fast* detection of component-link failures in a LAG is: o= perational simplicity, clear and simple. >=20 > The problem with 802.1ag/Y.1731 is the massive amount of, potentially err= or-prone, configuration required. Take a moment and think about how many v= ariables are *required* to properly set-up 802.1ag/Y.1731: > a) What MD "name" should you use? > b) What MD "name format" should you use, (ASCII, DNS, etc.)? > c) What MD "level" should you use, (probably 0 or 1)? > d) What MEP ID's do I assign to each side of the link? > e) Don't forget to configure the right direction, up or down, for the ME= P? > ... that is *ridiculous*! >=20 > Let's not forget that there are [potentially] 100's if not 1,000's of LAG= 's in each carrier's network, so this needs to get repeated over and over a= nd over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up = *and* maintain. =20 >=20 > BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx} = interval". (The "multiplier" should default to 3, unless you want to confi= gure it differently). That's it! Done! >=20 > So, in short, let me throw my hat in the ring with other operators that I= really, really, really want a standards-based way of running BFD over comp= onent-links in a LAG in order to quickly detect a component-link failure an= d take it out of the bundle. >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 >> I think (and this is also what Shahram was alluding to) that BFD is mean= t to detect IP liveliness. This means that if I run BFD over an IP interfac= e it should bring it down only when the IP connectivity goes down. Shouldn'= t BFD be oblivious to the number of links alive in a LAG as long as the LAG= remains up and it can reach the other end. It is a simple implementation e= ffort to note the status of each component link of a lag and to bring it do= wn if the number goes below a certain threshold - You don't need to run BFD= over each link! >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>> Sent: Saturday, July 30, 2011 3:34 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hello Manav, >>>=20 >>> others have already replied but the part "[...] has no=20 >>> business" triggers now my reply. I deliberately=20 >>> "mis"-understand it. Point is that this is about business.=20 >>> Customers have pushed their vendors to implement BFD over LAG=20 >>> component links. Reasons I know >>>=20 >>> - LACP is not fast enough >>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>> Designers and Operations, so they would like to use it everywhere >>> - BFDs reputation for being fast and working >>>=20 >>>=20 >>> So now we have 3-4 different implementation for=20 >>> per-cmponent-link BFD that I know about. Potentially there=20 >>> exists more. Probably not that much different but enough to=20 >>> make interoperability impossible. It's again customers who=20 >>> push now for standardization. Thus the draft to find an agreement :-) >>>=20 >>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>> as I see two fundamental setups: (a) run BFD on every=20 >>> component link and (b) run a single BFD session over the LAG=20 >>> interface. They solve different network setups as far as I can see. >>>=20 >>>=20 >>> Regards, Marc >>>=20 >>>=20 >>>=20 >>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>=20 >>>> Hi Jeff, >>>>=20 >>>> Let me understand this. If you have an IP interface over a=20 >>> LAG with 5 component links, then you internally establish 5=20 >>> BFD sessions with 30ms timeouts? >>>>=20 >>>> You don't need to do this. You could use LACP for lag and=20 >>> BFD for IP connectivity - which means BFD should remain up as=20 >>> long as there is reachability over the lag. IMO it has no=20 >>> business to bother with each individual component links.=20 >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>> Sent: Friday, July 29, 2011 7:15 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We have been supporting this mode of BFD over LAG=20 >>> operations for last 5 years and our customers love it. >>>>=20 >>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>> hit min-links, do you really want to bring the LAG down? >>>>=20 >>>> Mach - be aware of patents :) >>>>=20 >>>> Regards, >>>> Jeff >>>>=20 >>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>> wrote: >>>>=20 >>>>> Hi Mach, >>>>>=20 >>>>> I am not sure I understand why you would want BFD to=20 >>> ensure liveliness of each component link in a LAG. The draft=20 >>> seems to suggest establishing separate BFD session for each=20 >>> pair of component interfaces to detect the failures. Why=20 >>> should BFD be concerned about each component link? I would=20 >>> rather that BFD sprays packets over each component link in a=20 >>> round robin fashion and brings down the IP interface over a=20 >>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org=20 >>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>> Behalf Of Mach Chen >>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We uploaded a new=20 >>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>> interface). You are very welcome to read the draft and give=20 >>> your comments. >>>>>=20 >>>>> Many thanks, >>>>> Mach >>>>=20 >>>=20 >>> -- >>> Marc Binderberger >>>=20 >>>=20 >=20 >=20 >=20 From davari@broadcom.com Sun Jul 31 18:12:10 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DD121F856A for ; Sun, 31 Jul 2011 18:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HorI-18VE7wz for ; Sun, 31 Jul 2011 18:12:08 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAB6121F8588 for ; Sun, 31 Jul 2011 18:12:08 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 31 Jul 2011 18:17:37 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 31 Jul 2011 18:12:02 -0700 From: "Shahram Davari" To: "'shane@castlepoint.net'" Date: Sun, 31 Jul 2011 18:12:01 -0700 Subject: Re: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxP2AXtHS+Wn/aOTz2QXtMUDHXRGQADl18GAABoSvg= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266F@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266E@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622B213A3DK6428419-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 01:12:10 -0000 Hi Shane and all Even if as you say BFD requires less configuration (which it doesn't) still= it can't justify doing unnecessary layer violation to proxy for Ethernet = OAM that already exists. Why not use BFD for OTN and PON OAM next. Thx Shahram Regards Shahram ----- Original Message ----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Sunday, July 31, 2011 06:00 PM=0A= To: 'shane@castlepoint.net' Cc: 'rtg-bfd@ietf.org' Subject: Re: Solicit comments on BFD for Interface draft Hi shane Same can be said about ethernet oam. Basically everything can be automatica= lly assigned by software except MDL. As someone who has implemented OAM and BFD, I can certainly say BFD require= s more variables and parameters. Regards Shahram=20 Regards Shahram ----- Original Message ----- From: Shane Amante [mailto:shane@castlepoint.net] Sent: Sunday, July 31, 2011 04:16 PM=0A= To: Shahram Davari Cc: Bhatia, Manav (Manav) ; rtg-bfd@ietf.o= rg Subject: Re: Solicit comments on BFD for Interface draft Hi Sharam, On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: > Hi Shane, >=20 > Same for BFD. You need to know my discriminator, your discriminator, loca= l IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand m= ode, Authentication, Active/Passive, Detection Interval, etc. As an _operator_ of BFD, I am not /required/ to configure every single vari= able you named above, on every single link of every router in my network. = Good try though. =20 Not to pick on any one implementation, but here's proof that the only requi= red **configuration elements** necessary to bring up BFD was the 'minimum-i= nterval', (specifying a period of 100 msecs): ---snip--- interface fe-0/0/6.0 { point-to-point; bfd-liveness-detection { minimum-interval 100; } } [...] > show bfd session=20 Detect Transmit Address State Interface Time Interval Multip= lier 10.200.2.0 Up fe-0/0/6.0 0.300 0.100 3 = =20 1 sessions, 1 clients Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps ---snip--- As with most IETF protocols, and particularly with smart & clever implement= ers designing & coding them, very sensible defaults are chosen so as to red= uce the configuration burden on behalf of operators. This is another way o= f saying, yes, as a [BFD] protocol implementer you need to worry that you'v= e implemented all of variables required by the RFC, either by forcing the o= perator to give you input for them or, better yet, by speaking to operators= and choosing to implement sensible defaults. > Believe me BFD requires more configuration than 802.1ag. So your argument= of requiring a lot of info to configure 802.1ag applies even more to BFD.= =20 The above would seem to indicate that's false. But, if you still don't bel= ieve me, here's a short configuration snippet showing all of the required c= onfiguration parameters to make IEEE 802.1ag work, on just a single link: ---snip--- ethernet { connectivity-fault-management { maintenance-domain myOrg { level 1; name-format character-string; maintenance-association link-MA { short-name-format character-string; continuity-check { interval 100ms; } mep 2 { interface ge-3/0/1; direction down; remote-mep 5; } } } } } ---snip--- For starters, as an operator, good luck on trying to keep all your MEP ID's= straight for every component-link inside every LAG! And, again, I'm not p= icking on any one vendor's configuration syntax ... the above is no differe= nt, and sometimes worse, on any other vendor I've configured 802.1ag/Y.1731= . In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the concl= usion that the designers of those protocols were likely operating under the= assumption, at that time, that a OSS and/or NMS would be used as the [sole= ] means to *configure* and *maintain* all of the configuration elements req= uired to bootstrap them and, when something goes wrong, figure out what inf= ormation is being reported by those protocols. Unfortunately, this is comp= letely *untrue* of how we run IP/MPLS networks -- namely, we don't use NMS = systems, particularly to configure our networks!, and thus we need somethin= g simple, that just works, i.e.: BFD. -shane >=20 > Regards > Shahram =20 >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Shane Amante > Sent: Saturday, July 30, 2011 9:36 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Manav, Sharam, Others, >=20 > On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >> I think the diagnoses is correct, but the medicine isn't! :-) >>=20 >> I completely agree that LACP is not fast enough and that operators also = want to detect individual component link breakdowns instead of the entire L= AG. If that's the case then folks should use IEEE 802.1ag for individual co= mponent links and BFD for the entire LAG. Are we trying to position BFD as = an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over c= omponent links since not all links may be ethernet? >=20 > The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 = (or 802.3ah) for *fast* detection of component-link failures in a LAG is: o= perational simplicity, clear and simple. >=20 > The problem with 802.1ag/Y.1731 is the massive amount of, potentially err= or-prone, configuration required. Take a moment and think about how many v= ariables are *required* to properly set-up 802.1ag/Y.1731: > a) What MD "name" should you use? > b) What MD "name format" should you use, (ASCII, DNS, etc.)? > c) What MD "level" should you use, (probably 0 or 1)? > d) What MEP ID's do I assign to each side of the link? > e) Don't forget to configure the right direction, up or down, for the ME= P? > ... that is *ridiculous*! >=20 > Let's not forget that there are [potentially] 100's if not 1,000's of LAG= 's in each carrier's network, so this needs to get repeated over and over a= nd over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up = *and* maintain. =20 >=20 > BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx} = interval". (The "multiplier" should default to 3, unless you want to confi= gure it differently). That's it! Done! >=20 > So, in short, let me throw my hat in the ring with other operators that I= really, really, really want a standards-based way of running BFD over comp= onent-links in a LAG in order to quickly detect a component-link failure an= d take it out of the bundle. >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 >> I think (and this is also what Shahram was alluding to) that BFD is mean= t to detect IP liveliness. This means that if I run BFD over an IP interfac= e it should bring it down only when the IP connectivity goes down. Shouldn'= t BFD be oblivious to the number of links alive in a LAG as long as the LAG= remains up and it can reach the other end. It is a simple implementation e= ffort to note the status of each component link of a lag and to bring it do= wn if the number goes below a certain threshold - You don't need to run BFD= over each link! >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>> Sent: Saturday, July 30, 2011 3:34 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hello Manav, >>>=20 >>> others have already replied but the part "[...] has no=20 >>> business" triggers now my reply. I deliberately=20 >>> "mis"-understand it. Point is that this is about business.=20 >>> Customers have pushed their vendors to implement BFD over LAG=20 >>> component links. Reasons I know >>>=20 >>> - LACP is not fast enough >>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>> Designers and Operations, so they would like to use it everywhere >>> - BFDs reputation for being fast and working >>>=20 >>>=20 >>> So now we have 3-4 different implementation for=20 >>> per-cmponent-link BFD that I know about. Potentially there=20 >>> exists more. Probably not that much different but enough to=20 >>> make interoperability impossible. It's again customers who=20 >>> push now for standardization. Thus the draft to find an agreement :-) >>>=20 >>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>> as I see two fundamental setups: (a) run BFD on every=20 >>> component link and (b) run a single BFD session over the LAG=20 >>> interface. They solve different network setups as far as I can see. >>>=20 >>>=20 >>> Regards, Marc >>>=20 >>>=20 >>>=20 >>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>=20 >>>> Hi Jeff, >>>>=20 >>>> Let me understand this. If you have an IP interface over a=20 >>> LAG with 5 component links, then you internally establish 5=20 >>> BFD sessions with 30ms timeouts? >>>>=20 >>>> You don't need to do this. You could use LACP for lag and=20 >>> BFD for IP connectivity - which means BFD should remain up as=20 >>> long as there is reachability over the lag. IMO it has no=20 >>> business to bother with each individual component links.=20 >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>> Sent: Friday, July 29, 2011 7:15 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We have been supporting this mode of BFD over LAG=20 >>> operations for last 5 years and our customers love it. >>>>=20 >>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>> hit min-links, do you really want to bring the LAG down? >>>>=20 >>>> Mach - be aware of patents :) >>>>=20 >>>> Regards, >>>> Jeff >>>>=20 >>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>> wrote: >>>>=20 >>>>> Hi Mach, >>>>>=20 >>>>> I am not sure I understand why you would want BFD to=20 >>> ensure liveliness of each component link in a LAG. The draft=20 >>> seems to suggest establishing separate BFD session for each=20 >>> pair of component interfaces to detect the failures. Why=20 >>> should BFD be concerned about each component link? I would=20 >>> rather that BFD sprays packets over each component link in a=20 >>> round robin fashion and brings down the IP interface over a=20 >>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org=20 >>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>> Behalf Of Mach Chen >>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We uploaded a new=20 >>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>> interface). You are very welcome to read the draft and give=20 >>> your comments. >>>>>=20 >>>>> Many thanks, >>>>> Mach >>>>=20 >>>=20 >>> -- >>> Marc Binderberger >>>=20 >>>=20 >=20 >=20 >=20 From shane@castlepoint.net Sun Jul 31 19:32:05 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6706421F8741 for ; Sun, 31 Jul 2011 19:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DrIsZBMekBM for ; Sun, 31 Jul 2011 19:32:04 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0439121F8568 for ; Sun, 31 Jul 2011 19:32:04 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0EBAE268037; Sun, 31 Jul 2011 20:32:09 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 31 Jul 2011 20:32:08 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=59518; syn-fingerprint=65535:54:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266F@SJEXCHCCR02.corp.ad.broadcom.com> Date: Sun, 31 Jul 2011 20:31:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266F@SJEXCHCCR02.corp.ad.broadcom.com> To: Shahram Davari X-Mailer: Apple Mail (2.1084) Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 02:32:05 -0000 Sharam, On Jul 31, 2011, at 7:12 PM, Shahram Davari wrote: > Hi Shane and all >=20 > Even if as you say BFD requires less configuration (which it doesn't) I noticed you haven't pointed toward an existing standard or, better = yet, implementation of said standard that would back your claim that = today's implementations of 802.1ag/Y.1731 are "less configuration" than = BFD ... > still it can't justify doing unnecessary layer violation to proxy for = Ethernet OAM that already exists. Why not use BFD for OTN and PON OAM = next. Let's be perfectly clear here. BFD is a fast, failure detection = mechanism that is [already] directly integrated into and directly drives = *routing* and *signaling* protocols for IP/MPLS networks. That was why = BFD was created and that is how it is being extensively used. And, = that's **how** we want to continue to use it, in this case on = component-links of LAG's between /routed/ devices, as we need to /scale/ = our networks beyond the capability of physical media. Ethernet OAM has it's place and will continue to have it's place, but = that's IMO [strictly] in L2 switched networks where one has no other = choice (since those devices are strictly L2 switches), either on: a) Directly adjacent links: 802.3ah or 802.1ag/Y.1731; or, b) Multiple hops: 802.1ag/Y.1731 ... but, Ethernet OAM is a huge pain-in-the-neck to configure and = operate, as I demonstrated. -shane > Thx > Shahram >=20 > Regards > Shahram >=20 > ----- Original Message ----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Sunday, July 31, 2011 06:00 PM > To: 'shane@castlepoint.net' > Cc: 'rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hi shane >=20 > Same can be said about ethernet oam. Basically everything can be = automatically assigned by software except MDL. >=20 > As someone who has implemented OAM and BFD, I can certainly say BFD = requires more variables and parameters. >=20 > Regards > Shahram=20 >=20 > Regards > Shahram >=20 > ----- Original Message ----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Sunday, July 31, 2011 04:16 PM > To: Shahram Davari > Cc: Bhatia, Manav (Manav) ; = rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hi Sharam, >=20 > On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: >> Hi Shane, >>=20 >> Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, = Demand mode, Authentication, Active/Passive, Detection Interval, etc. >=20 > As an _operator_ of BFD, I am not /required/ to configure every single = variable you named above, on every single link of every router in my = network. Good try though. =20 >=20 > Not to pick on any one implementation, but here's proof that the only = required **configuration elements** necessary to bring up BFD was the = 'minimum-interval', (specifying a period of 100 msecs): > ---snip--- > interface fe-0/0/6.0 { > point-to-point; > bfd-liveness-detection { > minimum-interval 100; > } > } > [...] >> show bfd session=20 > Detect Transmit > Address State Interface Time Interval = Multiplier > 10.200.2.0 Up fe-0/0/6.0 0.300 0.100 = 3 =20 >=20 > 1 sessions, 1 clients > Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps > ---snip--- >=20 > As with most IETF protocols, and particularly with smart & clever = implementers designing & coding them, very sensible defaults are chosen = so as to reduce the configuration burden on behalf of operators. This = is another way of saying, yes, as a [BFD] protocol implementer you need = to worry that you've implemented all of variables required by the RFC, = either by forcing the operator to give you input for them or, better = yet, by speaking to operators and choosing to implement sensible = defaults. >=20 >=20 >> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 >=20 > The above would seem to indicate that's false. But, if you still = don't believe me, here's a short configuration snippet showing all of = the required configuration parameters to make IEEE 802.1ag work, on just = a single link: > ---snip--- > ethernet { > connectivity-fault-management { > maintenance-domain myOrg { > level 1; > name-format character-string; > maintenance-association link-MA { > short-name-format character-string; > continuity-check { > interval 100ms; > } > mep 2 { > interface ge-3/0/1; > direction down; > remote-mep 5; > } > } > } > } > } > ---snip--- >=20 > For starters, as an operator, good luck on trying to keep all your MEP = ID's straight for every component-link inside every LAG! And, again, = I'm not picking on any one vendor's configuration syntax ... the above = is no different, and sometimes worse, on any other vendor I've = configured 802.1ag/Y.1731. >=20 > In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the = conclusion that the designers of those protocols were likely operating = under the assumption, at that time, that a OSS and/or NMS would be used = as the [sole] means to *configure* and *maintain* all of the = configuration elements required to bootstrap them and, when something = goes wrong, figure out what information is being reported by those = protocols. Unfortunately, this is completely *untrue* of how we run = IP/MPLS networks -- namely, we don't use NMS systems, particularly to = configure our networks!, and thus we need something simple, that just = works, i.e.: BFD. >=20 > -shane >=20 >=20 >=20 >>=20 >> Regards >> Shahram =20 >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >> Sent: Saturday, July 30, 2011 9:36 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Manav, Sharam, Others, >>=20 >> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>> I think the diagnoses is correct, but the medicine isn't! :-) >>>=20 >>> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >>=20 >> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>=20 >> The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how = many variables are *required* to properly set-up 802.1ag/Y.1731: >> a) What MD "name" should you use? >> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >> c) What MD "level" should you use, (probably 0 or 1)? >> d) What MEP ID's do I assign to each side of the link? >> e) Don't forget to configure the right direction, up or down, for = the MEP? >> ... that is *ridiculous*! >>=20 >> Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and = over and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex = to set-up *and* maintain. =20 >>=20 >> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>=20 >> So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >>=20 >> Thanks, >>=20 >> -shane >>=20 >>=20 >>=20 >>> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>> Sent: Saturday, July 30, 2011 3:34 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hello Manav, >>>>=20 >>>> others have already replied but the part "[...] has no=20 >>>> business" triggers now my reply. I deliberately=20 >>>> "mis"-understand it. Point is that this is about business.=20 >>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>> component links. Reasons I know >>>>=20 >>>> - LACP is not fast enough >>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>> Designers and Operations, so they would like to use it everywhere >>>> - BFDs reputation for being fast and working >>>>=20 >>>>=20 >>>> So now we have 3-4 different implementation for=20 >>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>> exists more. Probably not that much different but enough to=20 >>>> make interoperability impossible. It's again customers who=20 >>>> push now for standardization. Thus the draft to find an agreement = :-) >>>>=20 >>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>> as I see two fundamental setups: (a) run BFD on every=20 >>>> component link and (b) run a single BFD session over the LAG=20 >>>> interface. They solve different network setups as far as I can see. >>>>=20 >>>>=20 >>>> Regards, Marc >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> Hi Jeff, >>>>>=20 >>>>> Let me understand this. If you have an IP interface over a=20 >>>> LAG with 5 component links, then you internally establish 5=20 >>>> BFD sessions with 30ms timeouts? >>>>>=20 >>>>> You don't need to do this. You could use LACP for lag and=20 >>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>> long as there is reachability over the lag. IMO it has no=20 >>>> business to bother with each individual component links.=20 >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We have been supporting this mode of BFD over LAG=20 >>>> operations for last 5 years and our customers love it. >>>>>=20 >>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>> hit min-links, do you really want to bring the LAG down? >>>>>=20 >>>>> Mach - be aware of patents :) >>>>>=20 >>>>> Regards, >>>>> Jeff >>>>>=20 >>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>> wrote: >>>>>=20 >>>>>> Hi Mach, >>>>>>=20 >>>>>> I am not sure I understand why you would want BFD to=20 >>>> ensure liveliness of each component link in a LAG. The draft=20 >>>> seems to suggest establishing separate BFD session for each=20 >>>> pair of component interfaces to detect the failures. Why=20 >>>> should BFD be concerned about each component link? I would=20 >>>> rather that BFD sprays packets over each component link in a=20 >>>> round robin fashion and brings down the IP interface over a=20 >>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>> Behalf Of Mach Chen >>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>> To: rtg-bfd@ietf.org >>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We uploaded a new=20 >>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>> interface). You are very welcome to read the draft and give=20 >>>> your comments. >>>>>>=20 >>>>>> Many thanks, >>>>>> Mach >>>>>=20 >>>>=20 >>>> -- >>>> Marc Binderberger >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 From gregimirsky@gmail.com Sun Jul 31 20:23:09 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68421F84DD for ; Sun, 31 Jul 2011 20:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGbdz2PNt5Ho for ; Sun, 31 Jul 2011 20:23:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED9B521F84D3 for ; Sun, 31 Jul 2011 20:23:07 -0700 (PDT) Received: by vws12 with SMTP id 12so4942577vws.31 for ; Sun, 31 Jul 2011 20:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VEmh1VzIJKCmCVGLxpcNtI0ADEJrioypCyls6ZngnK4=; b=W013UUrl5waR6GAybGe0wQCZrGuaIsJ39IRujWJvy/YwuUHJUJBIhicI/Xe/SSWa6J csR2ZKV6Qk/e+QGhR8nuTCLyN0UjatmspQvltONoK/Ychm4ekZURPz9UzuhKWuMS5a0U gUDowX8/f0DAABfIOTOU+pCAfOH6pyuFx3KDA= MIME-Version: 1.0 Received: by 10.52.97.134 with SMTP id ea6mr3783978vdb.426.1312168991641; Sun, 31 Jul 2011 20:23:11 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Sun, 31 Jul 2011 20:23:11 -0700 (PDT) In-Reply-To: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266F@SJEXCHCCR02.corp.ad.broadcom.com> <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> Date: Sun, 31 Jul 2011 20:23:11 -0700 Message-ID: Subject: Re: Solicit comments on BFD for Interface draft From: Greg Mirsky To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 03:23:09 -0000 Dear Shane, I took liberty to google for IEEE 802.3ah and copy configuration example provided by one vendor: protocols { oam { ethernet { link-fault-management { interface xe-0/0/0 { link-discovery active; pdu-interval 800; pdu-threshold 4; remote-loopback; negotiation-options { allow-remote-loopback; } event-thresholds { frame-error 30; frame-period 50; frame-period summary 40; symbol-period 20; } } } } } If one chooses default values the whole configuration will look as: protocols { oam { ethernet { link-fault-management { interface xe-0/0/0 { link-discovery active; remote-loopback; negotiation-options { allow-remote-loopback; } } } } } } It doesn't look too complex to me (and it can be simplified even further). Regards, Greg On Sun, Jul 31, 2011 at 7:31 PM, Shane Amante wrote= : > Sharam, > > On Jul 31, 2011, at 7:12 PM, Shahram Davari wrote: >> Hi Shane and all >> >> Even if as you say BFD requires less configuration (which it doesn't) > > I noticed you haven't pointed toward an existing standard or, better yet,= implementation of said standard that would back your claim that today's im= plementations of 802.1ag/Y.1731 are "less configuration" than BFD ... > > >> still it can't justify doing unnecessary =A0layer violation to proxy for= Ethernet OAM that already exists. Why not use BFD for OTN and PON OAM next= . > > Let's be perfectly clear here. =A0BFD is a fast, failure detection mechan= ism that is [already] directly integrated into and directly drives *routing= * and *signaling* protocols for IP/MPLS networks. =A0That was why BFD was c= reated and that is how it is being extensively used. =A0And, that's **how**= we want to continue to use it, in this case on component-links of LAG's be= tween /routed/ devices, as we need to /scale/ our networks beyond the capab= ility of physical media. > > Ethernet OAM has it's place and will continue to have it's place, but tha= t's IMO [strictly] in L2 switched networks where one has no other choice (s= ince those devices are strictly L2 switches), either on: > a) =A0Directly adjacent links: 802.3ah or 802.1ag/Y.1731; or, > b) =A0Multiple hops: 802.1ag/Y.1731 > ... but, Ethernet OAM is a huge pain-in-the-neck to configure and operate= , as I demonstrated. > > -shane > > >> Thx >> Shahram >> >> Regards >> Shahram >> >> ----- Original Message ----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Sunday, July 31, 2011 06:00 PM >> To: 'shane@castlepoint.net' >> Cc: 'rtg-bfd@ietf.org' >> Subject: Re: Solicit comments on BFD for Interface draft >> >> Hi shane >> >> Same can be said about ethernet oam. Basically everything can be automat= ically assigned by software except MDL. >> >> As someone who has implemented OAM and BFD, I can certainly say BFD requ= ires more variables and parameters. >> >> Regards >> Shahram >> >> Regards >> Shahram >> >> ----- Original Message ----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Sunday, July 31, 2011 04:16 PM >> To: Shahram Davari >> Cc: Bhatia, Manav (Manav) ; rtg-bfd@iet= f.org >> Subject: Re: Solicit comments on BFD for Interface draft >> >> Hi Sharam, >> >> On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: >>> Hi Shane, >>> >>> Same for BFD. You need to know my discriminator, your discriminator, lo= cal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand= mode, Authentication, Active/Passive, Detection Interval, etc. >> >> As an _operator_ of BFD, I am not /required/ to configure every single v= ariable you named above, on every single link of every router in my network= . =A0Good try though. >> >> Not to pick on any one implementation, but here's proof that the only re= quired **configuration elements** necessary to bring up BFD was the 'minimu= m-interval', (specifying a period of 100 msecs): >> ---snip--- >> interface fe-0/0/6.0 { >> =A0 =A0point-to-point; >> =A0 =A0bfd-liveness-detection { >> =A0 =A0 =A0 =A0minimum-interval 100; >> =A0 =A0} >> } >> [...] >>> show bfd session >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Detect =A0 Transmit >> Address =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0State =A0 =A0 Interface =A0 = =A0 =A0Time =A0 =A0 Interval =A0Multiplier >> 10.200.2.0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Up =A0 =A0 =A0 =A0fe-0/0/6.0 =A0 = =A0 0.300 =A0 =A0 0.100 =A0 =A0 =A0 =A03 >> >> 1 sessions, 1 clients >> Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps >> ---snip--- >> >> As with most IETF protocols, and particularly with smart & clever implem= enters designing & coding them, very sensible defaults are chosen so as to = reduce the configuration burden on behalf of operators. =A0This is another = way of saying, yes, as a [BFD] protocol implementer you need to worry that = you've implemented all of variables required by the RFC, either by forcing = the operator to give you input for them or, better yet, by speaking to oper= ators and choosing to implement sensible defaults. >> >> >>> Believe me BFD requires more configuration than 802.1ag. So your argume= nt of requiring a lot of info to configure 802.1ag applies even more to BFD= . >> >> The above would seem to indicate that's false. =A0But, if you still don'= t believe me, here's a short configuration snippet showing all of the requi= red configuration parameters to make IEEE 802.1ag work, on just a single li= nk: >> ---snip--- >> ethernet { >> =A0 =A0connectivity-fault-management { >> =A0 =A0 =A0 =A0maintenance-domain myOrg { >> =A0 =A0 =A0 =A0 =A0 =A0level 1; >> =A0 =A0 =A0 =A0 =A0 =A0name-format character-string; >> =A0 =A0 =A0 =A0 =A0 =A0maintenance-association link-MA { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0short-name-format character-string; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continuity-check { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interval 100ms; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mep 2 { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interface ge-3/0/1; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0direction down; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remote-mep 5; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0} >> =A0 =A0} >> } >> ---snip--- >> >> For starters, as an operator, good luck on trying to keep all your MEP I= D's straight for every component-link inside every LAG! =A0And, again, I'm = not picking on any one vendor's configuration syntax ... the above is no di= fferent, and sometimes worse, on any other vendor I've configured 802.1ag/Y= .1731. >> >> In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the co= nclusion that the designers of those protocols were likely operating under = the assumption, at that time, that a OSS and/or NMS would be used as the [s= ole] means to *configure* and *maintain* all of the configuration elements = required to bootstrap them and, when something goes wrong, figure out what = information is being reported by those protocols. =A0Unfortunately, this is= completely *untrue* of how we run IP/MPLS networks -- namely, we don't use= NMS systems, particularly to configure our networks!, and thus we need som= ething simple, that just works, i.e.: BFD. >> >> -shane >> >> >> >>> >>> Regards >>> Shahram >>> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>> >>> Manav, Sharam, Others, >>> >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>> >>>> I completely agree that LACP is not fast enough and that operators als= o want to detect individual component link breakdowns instead of the entire= LAG. If that's the case then folks should use IEEE 802.1ag for individual = component links and BFD for the entire LAG. Are we trying to position BFD a= s an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over= component links since not all links may be ethernet? >>> >>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.173= 1 (or 802.3ah) for *fast* detection of component-link failures in a LAG is:= operational simplicity, clear and simple. >>> >>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially e= rror-prone, configuration required. =A0Take a moment and think about how ma= ny variables are *required* to properly set-up 802.1ag/Y.1731: >>> a) =A0What MD "name" should you use? >>> b) =A0What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) =A0What MD "level" should you use, (probably 0 or 1)? >>> d) =A0What MEP ID's do I assign to each side of the link? >>> e) =A0Don't forget to configure the right direction, up or down, for th= e MEP? >>> ... that is *ridiculous*! >>> >>> Let's not forget that there are [potentially] 100's if not 1,000's of L= AG's in each carrier's network, so this needs to get repeated over and over= and over again. =A0Bottom-line: 802.1ag/Y.1731 is extremely complex to set= -up *and* maintain. >>> >>> BFD is simple. =A0At a bare minimum you just need to configure an "{Tx|= Rx} interval". =A0(The "multiplier" should default to 3, unless you want to= configure it differently). That's it! =A0Done! >>> >>> So, in short, let me throw my hat in the ring with other operators that= I really, really, really want a standards-based way of running BFD over co= mponent-links in a LAG in order to quickly detect a component-link failure = and take it out of the bundle. >>> >>> Thanks, >>> >>> -shane >>> >>> >>> >>>> I think (and this is also what Shahram was alluding to) that BFD is me= ant to detect IP liveliness. This means that if I run BFD over an IP interf= ace it should bring it down only when the IP connectivity goes down. Should= n't BFD be oblivious to the number of links alive in a LAG as long as the L= AG remains up and it can reach the other end. It is a simple implementation= effort to note the status of each component link of a lag and to bring it = down if the number goes below a certain threshold - You don't need to run B= FD over each link! >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>> >>>>> Hello Manav, >>>>> >>>>> others have already replied but the part "[...] has no >>>>> business" triggers now my reply. I deliberately >>>>> "mis"-understand it. Point is that this is about business. >>>>> Customers have pushed their vendors to implement BFD over LAG >>>>> component links. Reasons I know >>>>> >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>> >>>>> >>>>> So now we have 3-4 different implementation for >>>>> per-cmponent-link BFD that I know about. Potentially there >>>>> exists more. Probably not that much different but enough to >>>>> make interoperability impossible. It's again customers who >>>>> push now for standardization. Thus the draft to find an agreement :-) >>>>> >>>>> Will there be only one solution for "BFD over LAG"? Not sure >>>>> as I see two fundamental setups: (a) run BFD on every >>>>> component link =A0and (b) run a single BFD session over the LAG >>>>> interface. They solve different network setups as far as I can see. >>>>> >>>>> >>>>> Regards, Marc >>>>> >>>>> >>>>> >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>> >>>>>> Hi Jeff, >>>>>> >>>>>> Let me understand this. If you have an IP interface over a >>>>> LAG with 5 component links, then you internally establish 5 >>>>> BFD sessions with 30ms timeouts? >>>>>> >>>>>> You don't need to do this. You could use LACP for lag and >>>>> BFD for IP connectivity - which means BFD should remain up as >>>>> long as there is reachability over the lag. IMO it has no >>>>> business to bother with each individual component links. >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>> >>>>>> Hi, >>>>>> >>>>>> We have been supporting this mode of BFD over LAG >>>>> operations for last 5 years and our customers love it. >>>>>> >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>>> hit min-links, do you really want to bring the LAG down? >>>>>> >>>>>> Mach - be aware of patents :) >>>>>> >>>>>> Regards, >>>>>> Jeff >>>>>> >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>>> wrote: >>>>>> >>>>>>> Hi Mach, >>>>>>> >>>>>>> I am not sure I understand why you would want BFD to >>>>> ensure liveliness of each component link in a LAG. The draft >>>>> seems to suggest establishing separate BFD session for each >>>>> pair of component interfaces to detect the failures. Why >>>>> should BFD be concerned about each component link? I would >>>>> rather that BFD sprays packets over each component link in a >>>>> round robin fashion and brings down the IP interface over a >>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org >>>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We uploaded a new >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>>> that is about BFD running over interface(e.g., LAG/Bundle >>>>> interface). You are very welcome to read the draft and give >>>>> your comments. >>>>>>> >>>>>>> Many thanks, >>>>>>> Mach >>>>>> >>>>> >>>>> -- >>>>> Marc Binderberger =A0 =A0 =A0 =A0 =A0 >>>>> >>>>> >>> >>> >>> >> >> >> >> >> > > From mach.chen@huawei.com Sun Jul 31 20:40:15 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6021F856B for ; Sun, 31 Jul 2011 20:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-3.884, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4uoi0y2gWc1 for ; Sun, 31 Jul 2011 20:40:13 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D150D21F856A for ; Sun, 31 Jul 2011 20:40:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800EF6CV3HW@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 11:40:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800CUBCV3M4@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 11:40:15 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACU17833; Mon, 01 Aug 2011 11:40:14 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 01 Aug 2011 11:40:12 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Mon, 01 Aug 2011 11:40:14 +0800 Date: Mon, 01 Aug 2011 03:40:13 +0000 From: Mach Chen Subject: =?gb2312?B?tPC4tDogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBk?= =?gb2312?Q?raft?= In-reply-to: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> X-Originating-IP: [172.24.2.41] To: Shane Amante , Shahram Davari Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMTXaSGUO8YfsvQESe7fRUbEFVi5UCgIrw//+AwoCAAAlGgIABSygAgAAZOoCAAR2YAIABcuqAgACPZACAABzigIAAA0OAgAAWUICAAJAP9Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266F@SJEXCHCCR02.corp.ad.broadcom.com> <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 03:40:15 -0000 SGkgU2hhbmUsIFNoYWhyYW0gYW5kIG90aGVycywNCg0KSnVzdCByZXR1cm5lZCBmcm9tIHRoZSBs b25nIHRyYXZlbCBhbmQgc3VycGlzZWQgdG8gZmluZCB0aGUgZW50aHVzaWFzdGljIGRpc2N1c3Np b25zIG9uIHRoZSBsaXN0ISBUaGFua3MgZm9yIHlvdXIgZGlzY3Vzc2lvbiBhbmQgY29tbWVudHMh DQoNClNoYW5lLCBJIGZ1bGx5IGFncmVlIHdpdGggaGVyZSEgSSBoZWFyZCB0aGUgc2FtZSByZXF1 aXJlbWVudHMgZnJvbSBzZXZlcmFsIFNQcyBhcyB3aGF0J3MgeW91IHNhaWQuIFRoYXQncyB0aGUg bWFpbiBtb3RpdmF0aW9uIGZvciB0aGUgZHJhZnQuIEFuZCBiaXNzaWNhbGx5LCBhcyBNYXJjIGFu ZCBKZWZmIHNhaWQsIHRoZXJlIGFyZSBhY3R1YWxseSBzZXZlcmFsIGltcGxlbWV0YXRpb25zIGFu ZCBkZXBsb3ltZW50cyBpbiB0aGUgZmllbGQsIGl0IHByb3ZlZCB0aGF0IGl0IHJlYWxseSB3b3Jr cyBhbmQgZnVsbHkgc2F0aXNmeSB0aGUgcmVxdXJlaW1lbnRzIG9mIHRoZSBvcGVyYXRvcnMgKFVz aW5nIEplZmYncyB3b3JkLCBvcGVydG9ycyBsb3ZlIGl0Oi0pICkuDQoNCkkgaGF2ZSB0byBjbGFp bSB0aGF0IHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBkb2VzIG5vdCBpbnRlbmQgdG8gcmVwbGFjZSB0 aGUgZXhpc3RpbmcgRVRIIE9BTXMsIGl0J3MgY29tcGxlbWVudGFyeS4gSXQgZ2l2ZXMgdGhlIGNo YW5jZSB0byB0aGUgb3BlcmF0b3JzIHdobyBsb3ZlIHRvIHVzZSBCRkQuDQoNCkJ5IHRoZSB3YXks IHF1b3RlZCBmcm9tIFJGQyA1ODgwOg0KIlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcHJvdG9j b2wgaW50ZW5kZWQgdG8gZGV0ZWN0IGZhdWx0cyBpbiB0aGUNCiAgIGJpZGlyZWN0aW9uYWwgcGF0 aCBiZXR3ZWVuIHR3byBmb3J3YXJkaW5nIGVuZ2luZXMsIGluY2x1ZGluZw0KICAgaW50ZXJmYWNl cywgZGF0YSBsaW5rKHMpLCBhbmQgdG8gdGhlIGV4dGVudCBwb3NzaWJsZSB0aGUgZm9yd2FyZGlu Zw0KICAgZW5naW5lcyB0aGVtc2VsdmVzLCB3aXRoIHBvdGVudGlhbGx5IHZlcnkgbG93IGxhdGVu Y3kuIg0KDQpJIGludGVwcmV0IHRoaXMgYXMgQkZEIGNhbiBhbHNvIGFwcGx5IHRvIExBRyBhbmQg aXQgY29tcGVuZW50IGxpbmtzIGZvciBmYXVsdCBkZXRlY3RpbmcuIA0KDQpCZXN0IHJlZ2FyZHMs DQpNYWNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIFtydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gU2hhbmUgQW1hbnRlIFtzaGFuZUBjYXN0bGVwb2ludC5uZXRdDQq3osvNyrG85DogMjAxMcTq ONTCMcjVIDEwOjMxDQq1vTogU2hhaHJhbSBEYXZhcmkNCkNjOiAncnRnLWJmZEBpZXRmLm9yZycN Ctb3zOI6IFJlOiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0DQoN ClNoYXJhbSwNCg0KT24gSnVsIDMxLCAyMDExLCBhdCA3OjEyIFBNLCBTaGFocmFtIERhdmFyaSB3 cm90ZToNCj4gSGkgU2hhbmUgYW5kIGFsbA0KPg0KPiBFdmVuIGlmIGFzIHlvdSBzYXkgQkZEIHJl cXVpcmVzIGxlc3MgY29uZmlndXJhdGlvbiAod2hpY2ggaXQgZG9lc24ndCkNCg0KSSBub3RpY2Vk IHlvdSBoYXZlbid0IHBvaW50ZWQgdG93YXJkIGFuIGV4aXN0aW5nIHN0YW5kYXJkIG9yLCBiZXR0 ZXIgeWV0LCBpbXBsZW1lbnRhdGlvbiBvZiBzYWlkIHN0YW5kYXJkIHRoYXQgd291bGQgYmFjayB5 b3VyIGNsYWltIHRoYXQgdG9kYXkncyBpbXBsZW1lbnRhdGlvbnMgb2YgODAyLjFhZy9ZLjE3MzEg YXJlICJsZXNzIGNvbmZpZ3VyYXRpb24iIHRoYW4gQkZEIC4uLg0KDQoNCj4gc3RpbGwgaXQgY2Fu J3QganVzdGlmeSBkb2luZyB1bm5lY2Vzc2FyeSAgbGF5ZXIgdmlvbGF0aW9uIHRvIHByb3h5IGZv ciBFdGhlcm5ldCBPQU0gdGhhdCBhbHJlYWR5IGV4aXN0cy4gV2h5IG5vdCB1c2UgQkZEIGZvciBP VE4gYW5kIFBPTiBPQU0gbmV4dC4NCg0KTGV0J3MgYmUgcGVyZmVjdGx5IGNsZWFyIGhlcmUuICBC RkQgaXMgYSBmYXN0LCBmYWlsdXJlIGRldGVjdGlvbiBtZWNoYW5pc20gdGhhdCBpcyBbYWxyZWFk eV0gZGlyZWN0bHkgaW50ZWdyYXRlZCBpbnRvIGFuZCBkaXJlY3RseSBkcml2ZXMgKnJvdXRpbmcq IGFuZCAqc2lnbmFsaW5nKiBwcm90b2NvbHMgZm9yIElQL01QTFMgbmV0d29ya3MuICBUaGF0IHdh cyB3aHkgQkZEIHdhcyBjcmVhdGVkIGFuZCB0aGF0IGlzIGhvdyBpdCBpcyBiZWluZyBleHRlbnNp dmVseSB1c2VkLiAgQW5kLCB0aGF0J3MgKipob3cqKiB3ZSB3YW50IHRvIGNvbnRpbnVlIHRvIHVz ZSBpdCwgaW4gdGhpcyBjYXNlIG9uIGNvbXBvbmVudC1saW5rcyBvZiBMQUcncyBiZXR3ZWVuIC9y b3V0ZWQvIGRldmljZXMsIGFzIHdlIG5lZWQgdG8gL3NjYWxlLyBvdXIgbmV0d29ya3MgYmV5b25k IHRoZSBjYXBhYmlsaXR5IG9mIHBoeXNpY2FsIG1lZGlhLg0KDQpFdGhlcm5ldCBPQU0gaGFzIGl0 J3MgcGxhY2UgYW5kIHdpbGwgY29udGludWUgdG8gaGF2ZSBpdCdzIHBsYWNlLCBidXQgdGhhdCdz IElNTyBbc3RyaWN0bHldIGluIEwyIHN3aXRjaGVkIG5ldHdvcmtzIHdoZXJlIG9uZSBoYXMgbm8g b3RoZXIgY2hvaWNlIChzaW5jZSB0aG9zZSBkZXZpY2VzIGFyZSBzdHJpY3RseSBMMiBzd2l0Y2hl cyksIGVpdGhlciBvbjoNCmEpICBEaXJlY3RseSBhZGphY2VudCBsaW5rczogODAyLjNhaCBvciA4 MDIuMWFnL1kuMTczMTsgb3IsDQpiKSAgTXVsdGlwbGUgaG9wczogODAyLjFhZy9ZLjE3MzENCi4u LiBidXQsIEV0aGVybmV0IE9BTSBpcyBhIGh1Z2UgcGFpbi1pbi10aGUtbmVjayB0byBjb25maWd1 cmUgYW5kIG9wZXJhdGUsIGFzIEkgZGVtb25zdHJhdGVkLg0KDQotc2hhbmUNCg0KDQo+IFRoeA0K PiBTaGFocmFtDQo+DQo+IFJlZ2FyZHMNCj4gU2hhaHJhbQ0KPg0KPiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+IEZyb206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJpQGJyb2Fk Y29tLmNvbV0NCj4gU2VudDogU3VuZGF5LCBKdWx5IDMxLCAyMDExIDA2OjAwIFBNDQo+IFRvOiAn c2hhbmVAY2FzdGxlcG9pbnQubmV0JyA8c2hhbmVAY2FzdGxlcG9pbnQubmV0Pg0KPiBDYzogJ3J0 Zy1iZmRAaWV0Zi5vcmcnIDxydGctYmZkQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogU29saWNp dCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBkcmFmdA0KPg0KPiBIaSBzaGFuZQ0KPg0K PiBTYW1lIGNhbiBiZSBzYWlkIGFib3V0IGV0aGVybmV0IG9hbS4gQmFzaWNhbGx5IGV2ZXJ5dGhp bmcgY2FuIGJlIGF1dG9tYXRpY2FsbHkgYXNzaWduZWQgYnkgc29mdHdhcmUgZXhjZXB0IE1ETC4N Cj4NCj4gQXMgc29tZW9uZSB3aG8gaGFzIGltcGxlbWVudGVkIE9BTSBhbmQgQkZELCBJIGNhbiBj ZXJ0YWlubHkgc2F5IEJGRCByZXF1aXJlcyBtb3JlIHZhcmlhYmxlcyBhbmQgcGFyYW1ldGVycy4N Cj4NCj4gUmVnYXJkcw0KPiBTaGFocmFtDQo+DQo+IFJlZ2FyZHMNCj4gU2hhaHJhbQ0KPg0KPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206IFNoYW5lIEFtYW50ZSBbbWFpbHRv OnNoYW5lQGNhc3RsZXBvaW50Lm5ldF0NCj4gU2VudDogU3VuZGF5LCBKdWx5IDMxLCAyMDExIDA0 OjE2IFBNDQo+IFRvOiBTaGFocmFtIERhdmFyaQ0KPiBDYzogQmhhdGlhLCBNYW5hdiAoTWFuYXYp IDxtYW5hdi5iaGF0aWFAYWxjYXRlbC1sdWNlbnQuY29tPjsgcnRnLWJmZEBpZXRmLm9yZyA8cnRn LWJmZEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFNvbGljaXQgY29tbWVudHMgb24gQkZEIGZv ciBJbnRlcmZhY2UgZHJhZnQNCj4NCj4gSGkgU2hhcmFtLA0KPg0KPiBPbiBKdWwgMzEsIDIwMTEs IGF0IDg6NDMgQU0sIFNoYWhyYW0gRGF2YXJpIHdyb3RlOg0KPj4gSGkgU2hhbmUsDQo+Pg0KPj4g U2FtZSBmb3IgQkZELiBZb3UgbmVlZCB0byBrbm93IG15IGRpc2NyaW1pbmF0b3IsIHlvdXIgZGlz Y3JpbWluYXRvciwgbG9jYWwgSVAgYWRkcmVzcywgcmVtb3RlIElQIGFkZHJlc3MsIE1pbiBUeCBJ bnRlcnZhbCwgTWluIFJ4IEludGVydmFsLCBEZW1hbmQgbW9kZSwgQXV0aGVudGljYXRpb24sIEFj dGl2ZS9QYXNzaXZlLCBEZXRlY3Rpb24gSW50ZXJ2YWwsIGV0Yy4NCj4NCj4gQXMgYW4gX29wZXJh dG9yXyBvZiBCRkQsIEkgYW0gbm90IC9yZXF1aXJlZC8gdG8gY29uZmlndXJlIGV2ZXJ5IHNpbmds ZSB2YXJpYWJsZSB5b3UgbmFtZWQgYWJvdmUsIG9uIGV2ZXJ5IHNpbmdsZSBsaW5rIG9mIGV2ZXJ5 IHJvdXRlciBpbiBteSBuZXR3b3JrLiAgR29vZCB0cnkgdGhvdWdoLg0KPg0KPiBOb3QgdG8gcGlj ayBvbiBhbnkgb25lIGltcGxlbWVudGF0aW9uLCBidXQgaGVyZSdzIHByb29mIHRoYXQgdGhlIG9u bHkgcmVxdWlyZWQgKipjb25maWd1cmF0aW9uIGVsZW1lbnRzKiogbmVjZXNzYXJ5IHRvIGJyaW5n IHVwIEJGRCB3YXMgdGhlICdtaW5pbXVtLWludGVydmFsJywgKHNwZWNpZnlpbmcgYSBwZXJpb2Qg b2YgMTAwIG1zZWNzKToNCj4gLS0tc25pcC0tLQ0KPiBpbnRlcmZhY2UgZmUtMC8wLzYuMCB7DQo+ ICAgIHBvaW50LXRvLXBvaW50Ow0KPiAgICBiZmQtbGl2ZW5lc3MtZGV0ZWN0aW9uIHsNCj4gICAg ICAgIG1pbmltdW0taW50ZXJ2YWwgMTAwOw0KPiAgICB9DQo+IH0NCj4gWy4uLl0NCj4+IHNob3cg YmZkIHNlc3Npb24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIERldGVjdCAgIFRyYW5zbWl0DQo+IEFkZHJlc3MgICAgICAgICAgICAgICAgICBTdGF0 ZSAgICAgSW50ZXJmYWNlICAgICAgVGltZSAgICAgSW50ZXJ2YWwgIE11bHRpcGxpZXINCj4gMTAu MjAwLjIuMCAgICAgICAgICAgICAgIFVwICAgICAgICBmZS0wLzAvNi4wICAgICAwLjMwMCAgICAg MC4xMDAgICAgICAgIDMNCj4NCj4gMSBzZXNzaW9ucywgMSBjbGllbnRzDQo+IEN1bXVsYXRpdmUg dHJhbnNtaXQgcmF0ZSAxMC4wIHBwcywgY3VtdWxhdGl2ZSByZWNlaXZlIHJhdGUgMTAuMCBwcHMN Cj4gLS0tc25pcC0tLQ0KPg0KPiBBcyB3aXRoIG1vc3QgSUVURiBwcm90b2NvbHMsIGFuZCBwYXJ0 aWN1bGFybHkgd2l0aCBzbWFydCAmIGNsZXZlciBpbXBsZW1lbnRlcnMgZGVzaWduaW5nICYgY29k aW5nIHRoZW0sIHZlcnkgc2Vuc2libGUgZGVmYXVsdHMgYXJlIGNob3NlbiBzbyBhcyB0byByZWR1 Y2UgdGhlIGNvbmZpZ3VyYXRpb24gYnVyZGVuIG9uIGJlaGFsZiBvZiBvcGVyYXRvcnMuICBUaGlz IGlzIGFub3RoZXIgd2F5IG9mIHNheWluZywgeWVzLCBhcyBhIFtCRkRdIHByb3RvY29sIGltcGxl bWVudGVyIHlvdSBuZWVkIHRvIHdvcnJ5IHRoYXQgeW91J3ZlIGltcGxlbWVudGVkIGFsbCBvZiB2 YXJpYWJsZXMgcmVxdWlyZWQgYnkgdGhlIFJGQywgZWl0aGVyIGJ5IGZvcmNpbmcgdGhlIG9wZXJh dG9yIHRvIGdpdmUgeW91IGlucHV0IGZvciB0aGVtIG9yLCBiZXR0ZXIgeWV0LCBieSBzcGVha2lu ZyB0byBvcGVyYXRvcnMgYW5kIGNob29zaW5nIHRvIGltcGxlbWVudCBzZW5zaWJsZSBkZWZhdWx0 cy4NCj4NCj4NCj4+IEJlbGlldmUgbWUgQkZEIHJlcXVpcmVzIG1vcmUgY29uZmlndXJhdGlvbiB0 aGFuIDgwMi4xYWcuIFNvIHlvdXIgYXJndW1lbnQgb2YgcmVxdWlyaW5nIGEgbG90IG9mIGluZm8g dG8gY29uZmlndXJlIDgwMi4xYWcgYXBwbGllcyBldmVuIG1vcmUgdG8gQkZELg0KPg0KPiBUaGUg YWJvdmUgd291bGQgc2VlbSB0byBpbmRpY2F0ZSB0aGF0J3MgZmFsc2UuICBCdXQsIGlmIHlvdSBz dGlsbCBkb24ndCBiZWxpZXZlIG1lLCBoZXJlJ3MgYSBzaG9ydCBjb25maWd1cmF0aW9uIHNuaXBw ZXQgc2hvd2luZyBhbGwgb2YgdGhlIHJlcXVpcmVkIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyB0 byBtYWtlIElFRUUgODAyLjFhZyB3b3JrLCBvbiBqdXN0IGEgc2luZ2xlIGxpbms6DQo+IC0tLXNu aXAtLS0NCj4gZXRoZXJuZXQgew0KPiAgICBjb25uZWN0aXZpdHktZmF1bHQtbWFuYWdlbWVudCB7 DQo+ICAgICAgICBtYWludGVuYW5jZS1kb21haW4gbXlPcmcgew0KPiAgICAgICAgICAgIGxldmVs IDE7DQo+ICAgICAgICAgICAgbmFtZS1mb3JtYXQgY2hhcmFjdGVyLXN0cmluZzsNCj4gICAgICAg ICAgICBtYWludGVuYW5jZS1hc3NvY2lhdGlvbiBsaW5rLU1BIHsNCj4gICAgICAgICAgICAgICAg c2hvcnQtbmFtZS1mb3JtYXQgY2hhcmFjdGVyLXN0cmluZzsNCj4gICAgICAgICAgICAgICAgY29u dGludWl0eS1jaGVjayB7DQo+ICAgICAgICAgICAgICAgICAgICBpbnRlcnZhbCAxMDBtczsNCj4g ICAgICAgICAgICAgICAgfQ0KPiAgICAgICAgICAgICAgICBtZXAgMiB7DQo+ICAgICAgICAgICAg ICAgICAgICBpbnRlcmZhY2UgZ2UtMy8wLzE7DQo+ICAgICAgICAgICAgICAgICAgICBkaXJlY3Rp b24gZG93bjsNCj4gICAgICAgICAgICAgICAgICAgIHJlbW90ZS1tZXAgNTsNCj4gICAgICAgICAg ICAgICAgfQ0KPiAgICAgICAgICAgIH0NCj4gICAgICAgIH0NCj4gICAgfQ0KPiB9DQo+IC0tLXNu aXAtLS0NCj4NCj4gRm9yIHN0YXJ0ZXJzLCBhcyBhbiBvcGVyYXRvciwgZ29vZCBsdWNrIG9uIHRy eWluZyB0byBrZWVwIGFsbCB5b3VyIE1FUCBJRCdzIHN0cmFpZ2h0IGZvciBldmVyeSBjb21wb25l bnQtbGluayBpbnNpZGUgZXZlcnkgTEFHISAgQW5kLCBhZ2FpbiwgSSdtIG5vdCBwaWNraW5nIG9u IGFueSBvbmUgdmVuZG9yJ3MgY29uZmlndXJhdGlvbiBzeW50YXggLi4uIHRoZSBhYm92ZSBpcyBu byBkaWZmZXJlbnQsIGFuZCBzb21ldGltZXMgd29yc2UsIG9uIGFueSBvdGhlciB2ZW5kb3IgSSd2 ZSBjb25maWd1cmVkIDgwMi4xYWcvWS4xNzMxLg0KPg0KPiBJbiBzdW1tYXJ5LCBhcyBJJ3ZlIHN0 dWRpZWQgSUVFRSA4MDIuMWFnL0lUVSBZLjE3MzEsIEkndmUgY29tZSB0byB0aGUgY29uY2x1c2lv biB0aGF0IHRoZSBkZXNpZ25lcnMgb2YgdGhvc2UgcHJvdG9jb2xzIHdlcmUgbGlrZWx5IG9wZXJh dGluZyB1bmRlciB0aGUgYXNzdW1wdGlvbiwgYXQgdGhhdCB0aW1lLCB0aGF0IGEgT1NTIGFuZC9v ciBOTVMgd291bGQgYmUgdXNlZCBhcyB0aGUgW3NvbGVdIG1lYW5zIHRvICpjb25maWd1cmUqIGFu ZCAqbWFpbnRhaW4qIGFsbCBvZiB0aGUgY29uZmlndXJhdGlvbiBlbGVtZW50cyByZXF1aXJlZCB0 byBib290c3RyYXAgdGhlbSBhbmQsIHdoZW4gc29tZXRoaW5nIGdvZXMgd3JvbmcsIGZpZ3VyZSBv dXQgd2hhdCBpbmZvcm1hdGlvbiBpcyBiZWluZyByZXBvcnRlZCBieSB0aG9zZSBwcm90b2NvbHMu ICBVbmZvcnR1bmF0ZWx5LCB0aGlzIGlzIGNvbXBsZXRlbHkgKnVudHJ1ZSogb2YgaG93IHdlIHJ1 biBJUC9NUExTIG5ldHdvcmtzIC0tIG5hbWVseSwgd2UgZG9uJ3QgdXNlIE5NUyBzeXN0ZW1zLCBw YXJ0aWN1bGFybHkgdG8gY29uZmlndXJlIG91ciBuZXR3b3JrcyEsIGFuZCB0aHVzIHdlIG5lZWQg c29tZXRoaW5nIHNpbXBsZSwgdGhhdCBqdXN0IHdvcmtzLCBpLmUuOiBCRkQuDQo+DQo+IC1zaGFu ZQ0KPg0KPg0KPg0KPj4NCj4+IFJlZ2FyZHMNCj4+IFNoYWhyYW0NCj4+DQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hhbmUgQW1hbnRlDQo+ PiBTZW50OiBTYXR1cmRheSwgSnVseSAzMCwgMjAxMSA5OjM2IEFNDQo+PiBUbzogQmhhdGlhLCBN YW5hdiAoTWFuYXYpDQo+PiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFNv bGljaXQgY29tbWVudHMgb24gQkZEIGZvciBJbnRlcmZhY2UgZHJhZnQNCj4+DQo+PiBNYW5hdiwg U2hhcmFtLCBPdGhlcnMsDQo+Pg0KPj4gT24gSnVsIDI5LCAyMDExLCBhdCA1OjM0IFBNLCBCaGF0 aWEsIE1hbmF2IChNYW5hdikgd3JvdGU6DQo+Pj4gSSB0aGluayB0aGUgZGlhZ25vc2VzIGlzIGNv cnJlY3QsIGJ1dCB0aGUgbWVkaWNpbmUgaXNuJ3QhIDotKQ0KPj4+DQo+Pj4gSSBjb21wbGV0ZWx5 IGFncmVlIHRoYXQgTEFDUCBpcyBub3QgZmFzdCBlbm91Z2ggYW5kIHRoYXQgb3BlcmF0b3JzIGFs c28gd2FudCB0byBkZXRlY3QgaW5kaXZpZHVhbCBjb21wb25lbnQgbGluayBicmVha2Rvd25zIGlu c3RlYWQgb2YgdGhlIGVudGlyZSBMQUcuIElmIHRoYXQncyB0aGUgY2FzZSB0aGVuIGZvbGtzIHNo b3VsZCB1c2UgSUVFRSA4MDIuMWFnIGZvciBpbmRpdmlkdWFsIGNvbXBvbmVudCBsaW5rcyBhbmQg QkZEIGZvciB0aGUgZW50aXJlIExBRy4gQXJlIHdlIHRyeWluZyB0byBwb3NpdGlvbiBCRkQgYXMg YW4gSUVURiBlcXVpdmFsZW50IG9mIDgwMi4xYWc/IE9yIGlzIGl0IHRoYXQgd2UncmUgdHJ5aW5n IHRvIHJ1biBCRkQgb3ZlciBjb21wb25lbnQgbGlua3Mgc2luY2Ugbm90IGFsbCBsaW5rcyBtYXkg YmUgZXRoZXJuZXQ/DQo+Pg0KPj4gVGhlIG1haW4gcmVhc29uICh3ZSkgb3BlcmF0b3JzIHdhbnQg dG8gdXNlIEJGRCBpbnN0ZWFkIG9mIDgwMi4xYWcvWS4xNzMxIChvciA4MDIuM2FoKSBmb3IgKmZh c3QqIGRldGVjdGlvbiBvZiBjb21wb25lbnQtbGluayBmYWlsdXJlcyBpbiBhIExBRyBpczogb3Bl cmF0aW9uYWwgc2ltcGxpY2l0eSwgY2xlYXIgYW5kIHNpbXBsZS4NCj4+DQo+PiBUaGUgcHJvYmxl bSB3aXRoIDgwMi4xYWcvWS4xNzMxIGlzIHRoZSBtYXNzaXZlIGFtb3VudCBvZiwgcG90ZW50aWFs bHkgZXJyb3ItcHJvbmUsIGNvbmZpZ3VyYXRpb24gcmVxdWlyZWQuICBUYWtlIGEgbW9tZW50IGFu ZCB0aGluayBhYm91dCBob3cgbWFueSB2YXJpYWJsZXMgYXJlICpyZXF1aXJlZCogdG8gcHJvcGVy bHkgc2V0LXVwIDgwMi4xYWcvWS4xNzMxOg0KPj4gYSkgIFdoYXQgTUQgIm5hbWUiIHNob3VsZCB5 b3UgdXNlPw0KPj4gYikgIFdoYXQgTUQgIm5hbWUgZm9ybWF0IiBzaG91bGQgeW91IHVzZSwgKEFT Q0lJLCBETlMsIGV0Yy4pPw0KPj4gYykgIFdoYXQgTUQgImxldmVsIiBzaG91bGQgeW91IHVzZSwg KHByb2JhYmx5IDAgb3IgMSk/DQo+PiBkKSAgV2hhdCBNRVAgSUQncyBkbyBJIGFzc2lnbiB0byBl YWNoIHNpZGUgb2YgdGhlIGxpbms/DQo+PiBlKSAgRG9uJ3QgZm9yZ2V0IHRvIGNvbmZpZ3VyZSB0 aGUgcmlnaHQgZGlyZWN0aW9uLCB1cCBvciBkb3duLCBmb3IgdGhlIE1FUD8NCj4+IC4uLiB0aGF0 IGlzICpyaWRpY3Vsb3VzKiENCj4+DQo+PiBMZXQncyBub3QgZm9yZ2V0IHRoYXQgdGhlcmUgYXJl IFtwb3RlbnRpYWxseV0gMTAwJ3MgaWYgbm90IDEsMDAwJ3Mgb2YgTEFHJ3MgaW4gZWFjaCBjYXJy aWVyJ3MgbmV0d29yaywgc28gdGhpcyBuZWVkcyB0byBnZXQgcmVwZWF0ZWQgb3ZlciBhbmQgb3Zl ciBhbmQgb3ZlciBhZ2Fpbi4gIEJvdHRvbS1saW5lOiA4MDIuMWFnL1kuMTczMSBpcyBleHRyZW1l bHkgY29tcGxleCB0byBzZXQtdXAgKmFuZCogbWFpbnRhaW4uDQo+Pg0KPj4gQkZEIGlzIHNpbXBs ZS4gIEF0IGEgYmFyZSBtaW5pbXVtIHlvdSBqdXN0IG5lZWQgdG8gY29uZmlndXJlIGFuICJ7VHh8 Unh9IGludGVydmFsIi4gIChUaGUgIm11bHRpcGxpZXIiIHNob3VsZCBkZWZhdWx0IHRvIDMsIHVu bGVzcyB5b3Ugd2FudCB0byBjb25maWd1cmUgaXQgZGlmZmVyZW50bHkpLiBUaGF0J3MgaXQhICBE b25lIQ0KPj4NCj4+IFNvLCBpbiBzaG9ydCwgbGV0IG1lIHRocm93IG15IGhhdCBpbiB0aGUgcmlu ZyB3aXRoIG90aGVyIG9wZXJhdG9ycyB0aGF0IEkgcmVhbGx5LCByZWFsbHksIHJlYWxseSB3YW50 IGEgc3RhbmRhcmRzLWJhc2VkIHdheSBvZiBydW5uaW5nIEJGRCBvdmVyIGNvbXBvbmVudC1saW5r cyBpbiBhIExBRyBpbiBvcmRlciB0byBxdWlja2x5IGRldGVjdCBhIGNvbXBvbmVudC1saW5rIGZh aWx1cmUgYW5kIHRha2UgaXQgb3V0IG9mIHRoZSBidW5kbGUuDQo+Pg0KPj4gVGhhbmtzLA0KPj4N Cj4+IC1zaGFuZQ0KPj4NCj4+DQo+Pg0KPj4+IEkgdGhpbmsgKGFuZCB0aGlzIGlzIGFsc28gd2hh dCBTaGFocmFtIHdhcyBhbGx1ZGluZyB0bykgdGhhdCBCRkQgaXMgbWVhbnQgdG8gZGV0ZWN0IElQ IGxpdmVsaW5lc3MuIFRoaXMgbWVhbnMgdGhhdCBpZiBJIHJ1biBCRkQgb3ZlciBhbiBJUCBpbnRl cmZhY2UgaXQgc2hvdWxkIGJyaW5nIGl0IGRvd24gb25seSB3aGVuIHRoZSBJUCBjb25uZWN0aXZp dHkgZ29lcyBkb3duLiBTaG91bGRuJ3QgQkZEIGJlIG9ibGl2aW91cyB0byB0aGUgbnVtYmVyIG9m IGxpbmtzIGFsaXZlIGluIGEgTEFHIGFzIGxvbmcgYXMgdGhlIExBRyByZW1haW5zIHVwIGFuZCBp dCBjYW4gcmVhY2ggdGhlIG90aGVyIGVuZC4gSXQgaXMgYSBzaW1wbGUgaW1wbGVtZW50YXRpb24g ZWZmb3J0IHRvIG5vdGUgdGhlIHN0YXR1cyBvZiBlYWNoIGNvbXBvbmVudCBsaW5rIG9mIGEgbGFn IGFuZCB0byBicmluZyBpdCBkb3duIGlmIHRoZSBudW1iZXIgZ29lcyBiZWxvdyBhIGNlcnRhaW4g dGhyZXNob2xkIC0gWW91IGRvbid0IG5lZWQgdG8gcnVuIEJGRCBvdmVyIGVhY2ggbGluayENCj4+ Pg0KPj4+IENoZWVycywgTWFuYXYNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+PiBGcm9tOiBNYXJjIEJpbmRlcmJlcmdlciBbbWFpbHRvOm1hcmNAc25pZmYuZGVdDQo+ Pj4+IFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDMwLCAyMDExIDM6MzQgQU0NCj4+Pj4gVG86IEJoYXRp YSwgTWFuYXYgKE1hbmF2KQ0KPj4+PiBDYzogSmVmZiBUYW50c3VyYTsgcnRnLWJmZEBpZXRmLm9y Zw0KPj4+PiBTdWJqZWN0OiBSZTogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFj ZSBkcmFmdA0KPj4+Pg0KPj4+PiBIZWxsbyBNYW5hdiwNCj4+Pj4NCj4+Pj4gb3RoZXJzIGhhdmUg YWxyZWFkeSByZXBsaWVkIGJ1dCB0aGUgcGFydCAiWy4uLl0gaGFzIG5vDQo+Pj4+IGJ1c2luZXNz IiB0cmlnZ2VycyBub3cgbXkgcmVwbHkuIEkgZGVsaWJlcmF0ZWx5DQo+Pj4+ICJtaXMiLXVuZGVy c3RhbmQgaXQuIFBvaW50IGlzIHRoYXQgdGhpcyBpcyBhYm91dCBidXNpbmVzcy4NCj4+Pj4gQ3Vz dG9tZXJzIGhhdmUgcHVzaGVkIHRoZWlyIHZlbmRvcnMgdG8gaW1wbGVtZW50IEJGRCBvdmVyIExB Rw0KPj4+PiBjb21wb25lbnQgbGlua3MuIFJlYXNvbnMgSSBrbm93DQo+Pj4+DQo+Pj4+IC0gTEFD UCBpcyBub3QgZmFzdCBlbm91Z2gNCj4+Pj4gLSBCRkQgaW4gaXQncyBJUCBmb3JtIChJUCtVRFAr QkZEKSBpcyB1bmRlcnN0b29kIGJ5IFRlbGNvDQo+Pj4+IERlc2lnbmVycyBhbmQgT3BlcmF0aW9u cywgc28gdGhleSB3b3VsZCBsaWtlIHRvIHVzZSBpdCBldmVyeXdoZXJlDQo+Pj4+IC0gQkZEcyBy ZXB1dGF0aW9uIGZvciBiZWluZyBmYXN0IGFuZCB3b3JraW5nDQo+Pj4+DQo+Pj4+DQo+Pj4+IFNv IG5vdyB3ZSBoYXZlIDMtNCBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb24gZm9yDQo+Pj4+IHBlci1j bXBvbmVudC1saW5rIEJGRCB0aGF0IEkga25vdyBhYm91dC4gUG90ZW50aWFsbHkgdGhlcmUNCj4+ Pj4gZXhpc3RzIG1vcmUuIFByb2JhYmx5IG5vdCB0aGF0IG11Y2ggZGlmZmVyZW50IGJ1dCBlbm91 Z2ggdG8NCj4+Pj4gbWFrZSBpbnRlcm9wZXJhYmlsaXR5IGltcG9zc2libGUuIEl0J3MgYWdhaW4g Y3VzdG9tZXJzIHdobw0KPj4+PiBwdXNoIG5vdyBmb3Igc3RhbmRhcmRpemF0aW9uLiBUaHVzIHRo ZSBkcmFmdCB0byBmaW5kIGFuIGFncmVlbWVudCA6LSkNCj4+Pj4NCj4+Pj4gV2lsbCB0aGVyZSBi ZSBvbmx5IG9uZSBzb2x1dGlvbiBmb3IgIkJGRCBvdmVyIExBRyI/IE5vdCBzdXJlDQo+Pj4+IGFz IEkgc2VlIHR3byBmdW5kYW1lbnRhbCBzZXR1cHM6IChhKSBydW4gQkZEIG9uIGV2ZXJ5DQo+Pj4+ IGNvbXBvbmVudCBsaW5rICBhbmQgKGIpIHJ1biBhIHNpbmdsZSBCRkQgc2Vzc2lvbiBvdmVyIHRo ZSBMQUcNCj4+Pj4gaW50ZXJmYWNlLiBUaGV5IHNvbHZlIGRpZmZlcmVudCBuZXR3b3JrIHNldHVw cyBhcyBmYXIgYXMgSSBjYW4gc2VlLg0KPj4+Pg0KPj4+Pg0KPj4+PiBSZWdhcmRzLCBNYXJjDQo+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDIwMTEtMDctMjksIGF0IDQ6MTggQU0sIEJoYXRpYSwg TWFuYXYgKE1hbmF2KSB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIEplZmYsDQo+Pj4+Pg0KPj4+Pj4g TGV0IG1lIHVuZGVyc3RhbmQgdGhpcy4gSWYgeW91IGhhdmUgYW4gSVAgaW50ZXJmYWNlIG92ZXIg YQ0KPj4+PiBMQUcgd2l0aCA1IGNvbXBvbmVudCBsaW5rcywgdGhlbiB5b3UgaW50ZXJuYWxseSBl c3RhYmxpc2ggNQ0KPj4+PiBCRkQgc2Vzc2lvbnMgd2l0aCAzMG1zIHRpbWVvdXRzPw0KPj4+Pj4N Cj4+Pj4+IFlvdSBkb24ndCBuZWVkIHRvIGRvIHRoaXMuIFlvdSBjb3VsZCB1c2UgTEFDUCBmb3Ig bGFnIGFuZA0KPj4+PiBCRkQgZm9yIElQIGNvbm5lY3Rpdml0eSAtIHdoaWNoIG1lYW5zIEJGRCBz aG91bGQgcmVtYWluIHVwIGFzDQo+Pj4+IGxvbmcgYXMgdGhlcmUgaXMgcmVhY2hhYmlsaXR5IG92 ZXIgdGhlIGxhZy4gSU1PIGl0IGhhcyBubw0KPj4+PiBidXNpbmVzcyB0byBib3RoZXIgd2l0aCBl YWNoIGluZGl2aWR1YWwgY29tcG9uZW50IGxpbmtzLg0KPj4+Pj4NCj4+Pj4+IENoZWVycywgTWFu YXYNCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTog SmVmZiBUYW50c3VyYSBbbWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tXQ0KPj4+Pj4g U2VudDogRnJpZGF5LCBKdWx5IDI5LCAyMDExIDc6MTUgQU0NCj4+Pj4+IFRvOiBCaGF0aWEsIE1h bmF2IChNYW5hdikNCj4+Pj4+IENjOiBNYWNoIENoZW47IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+Pj4+ IFN1YmplY3Q6IFJlOiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0 DQo+Pj4+Pg0KPj4+Pj4gSGksDQo+Pj4+Pg0KPj4+Pj4gV2UgaGF2ZSBiZWVuIHN1cHBvcnRpbmcg dGhpcyBtb2RlIG9mIEJGRCBvdmVyIExBRw0KPj4+PiBvcGVyYXRpb25zIGZvciBsYXN0IDUgeWVh cnMgYW5kIG91ciBjdXN0b21lcnMgbG92ZSBpdC4NCj4+Pj4+DQo+Pj4+PiBNYW5hdiAtIGltYWdp bmUgeW91IGhhdmUgbG9zdCAzIG91dCBvZiA4IGxpbmtzIGJ1dCBkaWRuJ3QNCj4+Pj4gaGl0IG1p bi1saW5rcywgZG8geW91IHJlYWxseSB3YW50IHRvIGJyaW5nIHRoZSBMQUcgZG93bj8NCj4+Pj4+ DQo+Pj4+PiBNYWNoIC0gYmUgYXdhcmUgb2YgcGF0ZW50cyA6KQ0KPj4+Pj4NCj4+Pj4+IFJlZ2Fy ZHMsDQo+Pj4+PiBKZWZmDQo+Pj4+Pg0KPj4+Pj4gT24gSnVsIDI4LCAyMDExLCBhdCAyMToyNSwg IkJoYXRpYSwgTWFuYXYgKE1hbmF2KSINCj4+Pj4gPG1hbmF2LmJoYXRpYUBhbGNhdGVsLWx1Y2Vu dC5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBIaSBNYWNoLA0KPj4+Pj4+DQo+Pj4+Pj4gSSBh bSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2h5IHlvdSB3b3VsZCB3YW50IEJGRCB0bw0KPj4+PiBl bnN1cmUgbGl2ZWxpbmVzcyBvZiBlYWNoIGNvbXBvbmVudCBsaW5rIGluIGEgTEFHLiBUaGUgZHJh ZnQNCj4+Pj4gc2VlbXMgdG8gc3VnZ2VzdCBlc3RhYmxpc2hpbmcgc2VwYXJhdGUgQkZEIHNlc3Np b24gZm9yIGVhY2gNCj4+Pj4gcGFpciBvZiBjb21wb25lbnQgaW50ZXJmYWNlcyB0byBkZXRlY3Qg dGhlIGZhaWx1cmVzLiBXaHkNCj4+Pj4gc2hvdWxkIEJGRCBiZSBjb25jZXJuZWQgYWJvdXQgZWFj aCBjb21wb25lbnQgbGluaz8gSSB3b3VsZA0KPj4+PiByYXRoZXIgdGhhdCBCRkQgc3ByYXlzIHBh Y2tldHMgb3ZlciBlYWNoIGNvbXBvbmVudCBsaW5rIGluIGENCj4+Pj4gcm91bmQgcm9iaW4gZmFz aGlvbiBhbmQgYnJpbmdzIGRvd24gdGhlIElQIGludGVyZmFjZSBvdmVyIGENCj4+Pj4gbGFnIG9u bHkgaWYgaXQgbWlzc2VzIDMgY29uc2VjdXRpdmUgcGFja2V0cy4gQW0gSSBtaXNzaW5nIHNvbWV0 aGluZz8NCj4+Pj4+Pg0KPj4+Pj4+IENoZWVycywgTWFuYXYNCj4+Pj4+Pg0KPj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogcnRnLWJmZC1ib3VuY2VzQGlldGYu b3JnDQo+Pj4+IFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+Pj4+IEJl aGFsZiBPZiBNYWNoIENoZW4NCj4+Pj4+PiBTZW50OiBGcmlkYXksIEp1bHkgMjksIDIwMTEgNDow NSBBTQ0KPj4+Pj4+IFRvOiBydGctYmZkQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogU29saWNp dCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBkcmFmdA0KPj4+Pj4+DQo+Pj4+Pj4gSGks DQo+Pj4+Pj4NCj4+Pj4+PiBXZSB1cGxvYWRlZCBhIG5ldw0KPj4+PiBkcmFmdChodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWJmZC1pbnRlcmZhY2UtMDApDQo+Pj4+IHRoYXQg aXMgYWJvdXQgQkZEIHJ1bm5pbmcgb3ZlciBpbnRlcmZhY2UoZS5nLiwgTEFHL0J1bmRsZQ0KPj4+ PiBpbnRlcmZhY2UpLiBZb3UgYXJlIHZlcnkgd2VsY29tZSB0byByZWFkIHRoZSBkcmFmdCBhbmQg Z2l2ZQ0KPj4+PiB5b3VyIGNvbW1lbnRzLg0KPj4+Pj4+DQo+Pj4+Pj4gTWFueSB0aGFua3MsDQo+ Pj4+Pj4gTWFjaA0KPj4+Pj4NCj4+Pj4NCj4+Pj4gLS0NCj4+Pj4gTWFyYyBCaW5kZXJiZXJnZXIg ICAgICAgICAgIDxtYXJjQHNuaWZmLmRlPg0KPj4+Pg0KPj4+Pg0KPj4NCj4+DQo+Pg0KPg0KPg0K Pg0KPg0KPg== From davari@broadcom.com Sun Jul 31 21:44:32 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0921421F84E1 for ; Sun, 31 Jul 2011 21:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3OnICPDKaw7 for ; Sun, 31 Jul 2011 21:44:30 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE55E21F8797 for ; Sun, 31 Jul 2011 21:44:30 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 31 Jul 2011 21:49:55 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 31 Jul 2011 21:44:20 -0700 From: "Shahram Davari" To: "'shane@castlepoint.net'" Date: Sun, 31 Jul 2011 21:44:20 -0700 Subject: Re: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxP8zu5EB2ejVyZRZaWVe41PCcTqQAEnHAt Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6228EFF93DK6468810-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 04:44:32 -0000 Shane Let's forget about the configuration complexity since we can't agree on it = and stick to technical discussions on why I think this draft is a bad idea= . First, Could you please explain your protocol layering model. Do we now nee= d 2 IP layers, one before LAG termination and one after LAG termination, wh= ere the one before LAG termination only understands the well known Multicas= t IPDA. Or implementing this draft assumes bypassing LAG termination when IP-DA is= the known multicast proposed in the draft. In other words now LAG terminat= ion is conditional on IP address. Both are hacky implementation in my opinion. Second, if I am generating BFD in a central processor, how do I send this L= ink BFD to the desired Link? LAG algorithm will distribute it according to = its hash function. Doesn't it? Or do we now need to have per Link BFD gener= ator? Thanks Shahram ----- Original Message ----- From: Shane Amante [mailto:shane@castlepoint.net] Sent: Sunday, July 31, 2011 07:31 PM=0A= To: Shahram Davari Cc: 'rtg-bfd@ietf.org' Subject: Re: Solicit comments on BFD for Interface draft Sharam, On Jul 31, 2011, at 7:12 PM, Shahram Davari wrote: > Hi Shane and all >=20 > Even if as you say BFD requires less configuration (which it doesn't) I noticed you haven't pointed toward an existing standard or, better yet, i= mplementation of said standard that would back your claim that today's impl= ementations of 802.1ag/Y.1731 are "less configuration" than BFD ... > still it can't justify doing unnecessary layer violation to proxy for Et= hernet OAM that already exists. Why not use BFD for OTN and PON OAM next. Let's be perfectly clear here. BFD is a fast, failure detection mechanism = that is [already] directly integrated into and directly drives *routing* an= d *signaling* protocols for IP/MPLS networks. That was why BFD was created= and that is how it is being extensively used. And, that's **how** we want= to continue to use it, in this case on component-links of LAG's between /r= outed/ devices, as we need to /scale/ our networks beyond the capability of= physical media. Ethernet OAM has it's place and will continue to have it's place, but that'= s IMO [strictly] in L2 switched networks where one has no other choice (sin= ce those devices are strictly L2 switches), either on: a) Directly adjacent links: 802.3ah or 802.1ag/Y.1731; or, b) Multiple hops: 802.1ag/Y.1731 ... but, Ethernet OAM is a huge pain-in-the-neck to configure and operate, = as I demonstrated. -shane > Thx > Shahram >=20 > Regards > Shahram >=20 > ----- Original Message ----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Sunday, July 31, 2011 06:00 PM > To: 'shane@castlepoint.net' > Cc: 'rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hi shane >=20 > Same can be said about ethernet oam. Basically everything can be automati= cally assigned by software except MDL. >=20 > As someone who has implemented OAM and BFD, I can certainly say BFD requi= res more variables and parameters. >=20 > Regards > Shahram=20 >=20 > Regards > Shahram >=20 > ----- Original Message ----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Sunday, July 31, 2011 04:16 PM > To: Shahram Davari > Cc: Bhatia, Manav (Manav) ; rtg-bfd@ietf= .org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Hi Sharam, >=20 > On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: >> Hi Shane, >>=20 >> Same for BFD. You need to know my discriminator, your discriminator, loc= al IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand = mode, Authentication, Active/Passive, Detection Interval, etc. >=20 > As an _operator_ of BFD, I am not /required/ to configure every single va= riable you named above, on every single link of every router in my network.= Good try though. =20 >=20 > Not to pick on any one implementation, but here's proof that the only req= uired **configuration elements** necessary to bring up BFD was the 'minimum= -interval', (specifying a period of 100 msecs): > ---snip--- > interface fe-0/0/6.0 { > point-to-point; > bfd-liveness-detection { > minimum-interval 100; > } > } > [...] >> show bfd session=20 > Detect Transmit > Address State Interface Time Interval Mult= iplier > 10.200.2.0 Up fe-0/0/6.0 0.300 0.100 = 3 =20 >=20 > 1 sessions, 1 clients > Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps > ---snip--- >=20 > As with most IETF protocols, and particularly with smart & clever impleme= nters designing & coding them, very sensible defaults are chosen so as to r= educe the configuration burden on behalf of operators. This is another way= of saying, yes, as a [BFD] protocol implementer you need to worry that you= 've implemented all of variables required by the RFC, either by forcing the= operator to give you input for them or, better yet, by speaking to operato= rs and choosing to implement sensible defaults. >=20 >=20 >> Believe me BFD requires more configuration than 802.1ag. So your argumen= t of requiring a lot of info to configure 802.1ag applies even more to BFD.= =20 >=20 > The above would seem to indicate that's false. But, if you still don't b= elieve me, here's a short configuration snippet showing all of the required= configuration parameters to make IEEE 802.1ag work, on just a single link: > ---snip--- > ethernet { > connectivity-fault-management { > maintenance-domain myOrg { > level 1; > name-format character-string; > maintenance-association link-MA { > short-name-format character-string; > continuity-check { > interval 100ms; > } > mep 2 { > interface ge-3/0/1; > direction down; > remote-mep 5; > } > } > } > } > } > ---snip--- >=20 > For starters, as an operator, good luck on trying to keep all your MEP ID= 's straight for every component-link inside every LAG! And, again, I'm not= picking on any one vendor's configuration syntax ... the above is no diffe= rent, and sometimes worse, on any other vendor I've configured 802.1ag/Y.17= 31. >=20 > In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the con= clusion that the designers of those protocols were likely operating under t= he assumption, at that time, that a OSS and/or NMS would be used as the [so= le] means to *configure* and *maintain* all of the configuration elements r= equired to bootstrap them and, when something goes wrong, figure out what i= nformation is being reported by those protocols. Unfortunately, this is co= mpletely *untrue* of how we run IP/MPLS networks -- namely, we don't use NM= S systems, particularly to configure our networks!, and thus we need someth= ing simple, that just works, i.e.: BFD. >=20 > -shane >=20 >=20 >=20 >>=20 >> Regards >> Shahram =20 >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beha= lf Of Shane Amante >> Sent: Saturday, July 30, 2011 9:36 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Manav, Sharam, Others, >>=20 >> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>> I think the diagnoses is correct, but the medicine isn't! :-) >>>=20 >>> I completely agree that LACP is not fast enough and that operators also= want to detect individual component link breakdowns instead of the entire = LAG. If that's the case then folks should use IEEE 802.1ag for individual c= omponent links and BFD for the entire LAG. Are we trying to position BFD as= an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over = component links since not all links may be ethernet? >>=20 >> The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731= (or 802.3ah) for *fast* detection of component-link failures in a LAG is: = operational simplicity, clear and simple. >>=20 >> The problem with 802.1ag/Y.1731 is the massive amount of, potentially er= ror-prone, configuration required. Take a moment and think about how many = variables are *required* to properly set-up 802.1ag/Y.1731: >> a) What MD "name" should you use? >> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >> c) What MD "level" should you use, (probably 0 or 1)? >> d) What MEP ID's do I assign to each side of the link? >> e) Don't forget to configure the right direction, up or down, for the M= EP? >> ... that is *ridiculous*! >>=20 >> Let's not forget that there are [potentially] 100's if not 1,000's of LA= G's in each carrier's network, so this needs to get repeated over and over = and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up= *and* maintain. =20 >>=20 >> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx}= interval". (The "multiplier" should default to 3, unless you want to conf= igure it differently). That's it! Done! >>=20 >> So, in short, let me throw my hat in the ring with other operators that = I really, really, really want a standards-based way of running BFD over com= ponent-links in a LAG in order to quickly detect a component-link failure a= nd take it out of the bundle. >>=20 >> Thanks, >>=20 >> -shane >>=20 >>=20 >>=20 >>> I think (and this is also what Shahram was alluding to) that BFD is mea= nt to detect IP liveliness. This means that if I run BFD over an IP interfa= ce it should bring it down only when the IP connectivity goes down. Shouldn= 't BFD be oblivious to the number of links alive in a LAG as long as the LA= G remains up and it can reach the other end. It is a simple implementation = effort to note the status of each component link of a lag and to bring it d= own if the number goes below a certain threshold - You don't need to run BF= D over each link! >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>> Sent: Saturday, July 30, 2011 3:34 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hello Manav, >>>>=20 >>>> others have already replied but the part "[...] has no=20 >>>> business" triggers now my reply. I deliberately=20 >>>> "mis"-understand it. Point is that this is about business.=20 >>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>> component links. Reasons I know >>>>=20 >>>> - LACP is not fast enough >>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>> Designers and Operations, so they would like to use it everywhere >>>> - BFDs reputation for being fast and working >>>>=20 >>>>=20 >>>> So now we have 3-4 different implementation for=20 >>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>> exists more. Probably not that much different but enough to=20 >>>> make interoperability impossible. It's again customers who=20 >>>> push now for standardization. Thus the draft to find an agreement :-) >>>>=20 >>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>> as I see two fundamental setups: (a) run BFD on every=20 >>>> component link and (b) run a single BFD session over the LAG=20 >>>> interface. They solve different network setups as far as I can see. >>>>=20 >>>>=20 >>>> Regards, Marc >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> Hi Jeff, >>>>>=20 >>>>> Let me understand this. If you have an IP interface over a=20 >>>> LAG with 5 component links, then you internally establish 5=20 >>>> BFD sessions with 30ms timeouts? >>>>>=20 >>>>> You don't need to do this. You could use LACP for lag and=20 >>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>> long as there is reachability over the lag. IMO it has no=20 >>>> business to bother with each individual component links.=20 >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We have been supporting this mode of BFD over LAG=20 >>>> operations for last 5 years and our customers love it. >>>>>=20 >>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>> hit min-links, do you really want to bring the LAG down? >>>>>=20 >>>>> Mach - be aware of patents :) >>>>>=20 >>>>> Regards, >>>>> Jeff >>>>>=20 >>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>> wrote: >>>>>=20 >>>>>> Hi Mach, >>>>>>=20 >>>>>> I am not sure I understand why you would want BFD to=20 >>>> ensure liveliness of each component link in a LAG. The draft=20 >>>> seems to suggest establishing separate BFD session for each=20 >>>> pair of component interfaces to detect the failures. Why=20 >>>> should BFD be concerned about each component link? I would=20 >>>> rather that BFD sprays packets over each component link in a=20 >>>> round robin fashion and brings down the IP interface over a=20 >>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>> Behalf Of Mach Chen >>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>> To: rtg-bfd@ietf.org >>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We uploaded a new=20 >>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>> interface). You are very welcome to read the draft and give=20 >>>> your comments. >>>>>>=20 >>>>>> Many thanks, >>>>>> Mach >>>>>=20 >>>>=20 >>>> -- >>>> Marc Binderberger >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 From mach.chen@huawei.com Sun Jul 31 23:02:40 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C609D21F855D for ; Sun, 31 Jul 2011 23:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH3dx9UVJ10u for ; Sun, 31 Jul 2011 23:02:40 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC621F8556 for ; Sun, 31 Jul 2011 23:02:39 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800FQHJGGD6@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 14:02:40 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP80011GJGG0I@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 14:02:40 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACU29209; Mon, 01 Aug 2011 14:02:40 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 01 Aug 2011 14:02:39 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 01 Aug 2011 14:02:39 +0800 Date: Mon, 01 Aug 2011 06:02:39 +0000 From: Mach Chen Subject: =?utf-8?B?562U5aSNOiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNl?= =?utf-8?Q?_draft?= In-reply-to: X-Originating-IP: [172.24.2.41] To: Greg Mirsky Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMTXaSGUO8YfsvQESe7fRUbEFVi5UGmtyAgADIRK8= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 06:02:40 -0000 SGkgR3JlZywNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQoNClBsZWFzZSBzZWUg bXkgcmVwbHkgaW5saW5lLi4uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQrlj5Hku7bkuro6IEdyZWcgTWlyc2t5IFtncmVnaW1pcnNreUBnbWFpbC5jb21dDQrlj5Hp gIHml7bpl7Q6IDIwMTHlubQ45pyIMeaXpSA3OjU5DQrliLA6IE1hY2ggQ2hlbg0KQ2M6IHJ0Zy1i ZmRAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFNvbGljaXQgY29tbWVudHMgb24gQkZEIGZvciBJbnRl cmZhY2UgZHJhZnQNCg0KRGVhciBNYWNoIGFuZCBBbGwsDQpwbGVhc2UgZmluZCBteSBjb21tZW50 cyB0byB0aGUgZG9jdW1lbnQgYmVsb3c6DQrigKIgICAgICAgSW50cm9kdWN0aW9uIOKAnOKApmNv bnNlcXVlbnRseSB0YWtpbmcgZG93biBvciBicmluZ2luZyB1cCB0aGUNCmludGVyZmFjZXMgcmFw aWRseSBieSBCRkTigJ0gSSB0aGluayB0aGF0IHdlIGRvbuKAmXQgd2FudCB0byByZWFjdCB0bw0K ZXZlcnkgc3RhdGUgY2hhbmdlIG9mIGEgZmxhcHBpbmcgaW50ZXJmYWNlLiBCRkQgc2hvdWxkIG5v dCBiZSB0YWtpbmcNCmFueSBhY3Rpb25zIGJ1dCBvbmx5IHJlcG9ydCBzdGF0ZSBjaGFuZ2UuIFdo ZXRoZXIgbW9uaXRvcmVkIG9iamVjdCBpcw0KYWN0aXZhdGVkIG9yIGRlLWFjdGl2YXRlZCBpbW1l ZGlhdGVseSBvciB3aXRoIGRhbXBlbmVkIGRlbGF5IGlzDQpvdXRzaWRlIG9mIEJGRCBzY29wZS4N Cg0KW01hY2hdIFRoaXMgaXMgYSBnZW5lcmFsIGRlc2NyaXB0aW9uIG9uIGhvdyBCRkQgaXMgdXNl ZCBmb3IgaW50ZXJmYWNlLCBpdCBkb2VzIG5vdCByZXF1aXJlIHRoZSBpbXBsZW1lbnRhdGlvbiBo YXMgdG8gcmVhY3QgdGhlIHN0YXRlIGNoYW5nZSBpbW1lZGlhdGVseS4gWW91IGFyZSByaWdodCwg QkZEIGlzIHVzZWQgdG8gZGV0ZWN0IHRoZSBmYWlsdXJlIGFuZCByZXBvcnQgdGhlIGNoYW5nZSwg YW5kIHRoZSByZWFjdGlvbiBzaG91ZCBiZSB0YWtlbiBieSB0aGUgcmVsZXZhbnQgbW9kdWxlcyAo ZS5nLiwgaW50ZXJmYWNlIG1hbmFnZW1lbnQgbW9kdWxlKSBpZiB0aGV5IHRyYWNrIHRoZSByZWxh dGVkIEJGRCBzZXNzaW9uLiANCg0K4oCiICAgICAgIFNlY3Rpb24gMiDigJzigKZ3aGVuIHRoZSBp bnRlcmZhY2UgaXMgaXRzZWxmIHRoZSBjbGllbnQgb2YgdGhlIEJGRA0Kc2Vzc2lvbiwgdGhlbiB0 aGUgc3RhdHVzIG9mIHRoZSBpbnRlcmZhY2VzIHdpbGwgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0K c3RhdHVzIG9mIHRoZSBCRkQgc2Vzc2lvbi7igJ0gSeKAmWQgY2hhbmdlIHRoZSB0ZXh0IHRvIOKA nHRoZSBzdGF0dXMgb2YgdGhlDQppbnRlcmZhY2UgbWlnaHQgYmUgYXNzb2NpYXRlZCB3aXRoIHRo ZSBzdGF0dXMgb2YgdGhlIEJGRCBzZXNzaW9u4oCdLg0KDQpbTWFjaF0gT0ssIHdpbGwgY2hhbmdl IGl0IGluIG5leHQgdmVyaW9uLg0KDQrigKIgICAgICAgU2VjdGlvbiAyIOKAnFRvIGF2b2lkIHRo ZSBkZWFkbG9jayBCRkQgcGFja2V0cyBTSE9VTEQgTk9UIGJlIGJsb2NrZWQNCmJ5IHRoZSBsYXll ciBOIHByb3RvY29sIHN0YXR1cyBvZiB0aGUgaW50ZXJmYWNlIHdoZW4gdGhlIGFwcGxpY2F0aW9u DQpkZXBlbmRzIG9uIHRoZSBCRkQgc3RhdHVzIHRvIGVuYWJsZSBsYXllciBOIG9mIHRoZSBpbnRl cmZhY2Uu4oCdDQpXb3VsZG7igJl0IGl0IGJlIGNsZWFyZXIgdG8gYXNzb2NpYXRlIEJGRCBzZXNz aW9uIHdpdGggTGF5ZXIgTi0xIHRodXMNCm1ha2luZyBpdCBpbmRlcGVuZGVudCBvZiBzdGF0ZSBv ZiBMYXllciBOPw0KDQpbTWFjaF0gQWN0dWFsbHksIHRoZSBkcmFmdCBpbnRlbmRzIHRvIGFzc29j aWF0ZSBCRkQgc2Vzc2lvbiB3aXRoIExheWVyIE4gYW5kIGFsc28gcmVxdWlyZSB0aGF0IEJGRCBw YWNrZXRzIHRyYW5zbWl0aW9uIHNob3VsZCBiZSBpbmRlcGVuZGVudCBvZiB0aGUgc3RhdGUgb2Yg TGF5ZXIgTi4gIFRoYXQgaXMgd2h5IHRoZXJlIG1heSBiZSBkZWFkbG9jayB3aGVuIHVzaW5nIHRo ZSBub3JtYWwgbWVjaGFuaW1zIGFzIGN1cnJlbnQgZGVmaW5lZC4gDQoNCuKAoiAgICAgICBTZWN0 aW9uIDMuIEkgdGhpbmsgdGhhdCB3aGVuIGl0IHdpbGwgYmVuZWZpdCB0aGUgZG9jdW1lbnQgdG8g bWVudGlvbg0KdGhhdCB0aGUgVFRMIE1VU1QgYmUgc2V0IHRvIDEuIEl0IG1pZ2h0IGJlIG9idmlv dXMgYnV0IHdvdWxkIG5vdCBodXJ0DQp0byBtYWtlIGl0IGV4cGxpY2l0Lg0KDQpbTWFjaF0gV2ls bCBjb25zaWRlciB0aGlzIGluIG5leHQgdmVyc2lvLg0KDQrigKIgICAgICAgU2VjdGlvbiA0LiBG cm9tIGFuIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlIGl0IGlzIHVzdWFsbHkgYmV0dGVyDQp0 byByZWFjdCBpbW1lZGlhdGVseSB0byBhIERvd24gZXZlbnQgYW5kIGRlbGF5IG9yIGRhbXBlbiBV cCB0byBhdm9pZA0KZmxhcHBpbmcgZWZmZWN0Lg0KDQpUaGUgc3RhdHVzIG9mIGFuIGludGVyZmFj ZSBpcyBub3JtYWxseSByZWxhdGVkIHRvIG1hbnkgZmFjdG9ycyBhbmQgaXQncyBtb3JlIGltcGxl bWVudGF0aW9uIHNwZWNpZmljLCAgQkZEIHN0YXR1cyBpcyBqdXN0IG9uZSBvZiB0aGVtLiBBbiBp bnRlcmZhY2UgY291bGQgYXNsbyBpbXBsZW1lbnQgb3RoZXIgbWVjaGFuaW1zIChpbnRlcmZhY2Ug ZGFtcGluZykgdG8gYXZpb2QvcmVkdWNlIGZsYXBwaW5nLCBhbmQgQkZEIHN0YXR1cyBzaG91bGQg bm90IGV4Y2x1ZGUgdGhlbS4gIFdlIG1heSBhZGQgc29tZSB0ZXh0IHRvIGNsYXJpZnkgdGhpcyBp biBuZXh0IHJldmVyc2lvbi4NCg0K4oCiICAgICAgIFNlY3Rpb24gNSBJIGRpc2FncmVlIHRoYXQg dGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55DQpjaGFuZ2VzIHRvIFJGQyA1ODgw IGluIHJlZ2FyZCB0byBzZWN1cml0eS4gTWFraW5nIGludGVyZmFjZQ0KcHJvbWlzY3VvdXMgdG8g dGhlIG5ldyBtdWx0aWNhc3QgYWRkcmVzcyBhbmQgYWxsb3dpbmcgc291cmNlIGFkZHJlc3MNCnRv IGJlIDAuMC4wLjAgY2xlYXJseSBvcGVucyBhIG5ldyBkb29yIGZvciB0aGUgRG9TIGF0dGFja3Mu DQoNClllcywgeW91IGFyZSByaWdodCwgdGhlIHNlY3Rpb24gbmVlZHMgc29tZSByZXdvcmRpbmcu DQoNCuKAoiAgICAgICBJIHNlZSBhcyBhIGxpbWl0YXRpb24gdGhhdCB0aGUgcHJvcG9zYWwgZGVw ZW5kcyBvbiBJUCBhZGRyZXNzaW5nLA0KYWJpbGl0eSB0byBwcm9jZXNzIG5ldyBtdWx0aWNhc3Qg YWRkcmVzcy4gVGh1cyB0aGUgc2NvcGUgb2YgdGhlDQpkb2N1bWVudCwgaXRzIGFwcGxpY2FiaWxp dHkgaXMgbGltaXRlZCB0byBMQUcgaW50ZXJjb25uZWN0aW9ucyBiZXR3ZWVuDQpJUCBjYXBhYmxl IG5vZGVzLiBNUExTLVRQLCBmb3IgZXhhbXBsZSwgZG9lc27igJl0IGhhdmUgc3VjaCBsaW1pdGF0 aW9uDQp3aXRoIHVzZSBvZiBHLUFDaCBlbmNhcHN1bGF0aW9uLg0KDQpUaGUgZHJhZnQgY3VycmVu dGx5IGZvY3VzZXMgb24gdGhlIElQIGNhcGFibGUgbm9kZXMgb25seS4gDQoNClRoYW5rcyBhZ2Fp biBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRzIQ0KDQpCZXN0IHJlZ2FyZHMs DQpNYWNoDQoNCktpbmQgcmVnYXJkcywNCkdyZWcNCg0KT24gVGh1LCBKdWwgMjgsIDIwMTEgYXQg MzozNCBQTSwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+IEhpLA0K Pg0KPiBXZSB1cGxvYWRlZCBhIG5ldyBkcmFmdChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1jaGVuLWJmZC1pbnRlcmZhY2UtMDApIHRoYXQgaXMgYWJvdXQgQkZEIHJ1bm5pbmcgb3Zl ciBpbnRlcmZhY2UoZS5nLiwgTEFHL0J1bmRsZSBpbnRlcmZhY2UpLiBZb3UgYXJlIHZlcnkgd2Vs Y29tZSB0byByZWFkIHRoZSBkcmFmdCBhbmQgZ2l2ZSB5b3VyIGNvbW1lbnRzLg0KPg0KPiBNYW55 IHRoYW5rcywNCj4gTWFjaA0KPg== From Alexander.Vainshtein@ecitele.com Sun Jul 31 23:12:50 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1426F21F85C0 for ; Sun, 31 Jul 2011 23:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGGbf2QDbbEi for ; Sun, 31 Jul 2011 23:12:48 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id EC28B21F85AE for ; Sun, 31 Jul 2011 23:12:47 -0700 (PDT) X-AuditID: 93eaf2e8-b7ce7ae000000a69-2b-4e363d1a81ed Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 8D.D7.02665.A1D363E4; Mon, 1 Aug 2011 08:43:54 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 1 Aug 2011 09:12:47 +0300 From: Alexander Vainshtein To: Shahram Davari Date: Mon, 1 Aug 2011 09:09:57 +0300 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxP8zu5EB2ejVyZRZaWVe41PCcTqQAEnHAtAAL9kJc= Message-ID: References: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net>, <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.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="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0zTUBTHc9cyy6OmDscui49ajQ9kCwjoFIeKJoJGIKiJIgbLdt0at65Z CzpNFHzEBCXxibIP+EJFIGLUGA2aCESNxmfCBwQVk2GU4RONryCzpYgY++l/7/mf8zu3OYfA dJ+0RoLjJeTlWRejjcAPBnu/mIzWmVkJD0onWhrKMy2f+64Ay+uWJs18LMPf+UCb8au/ckRG dfUPTQ6WVwLmsjzvkVgJ0XYk2qxMjpcrZm0+hubsViaRoQUXa0NuxEtWhhUExNuZtAj6v2+u bON4GvE2j53jHVYmc3m2yWJJmW1KZNImT0xMSo1Y4eREGpncLOei3UgUWQei5Zt1lzHnze/l QAgUbXp4+hVeAmryywBBQCoZ9n/VlIFwWcbAxy8atGUggtBR1wAM9R3F1cNBAM/3HAlTXFrK Ci/WPdcqejQ1FTa1t2JKIYxaBwMfZynXODUJ1tfeHqHoaMoCL3QEBu2z4aXy4KCeA+uutQNF k1Q2fHL2Jaay9gHYEfg8wAqn8mBvyRVc0UDu7tu9+oFOMcoA27uODXZNwerrjzBV62F3oD9M 9evhs90NQPXHw+ONvVpVT4dnTvRgKngUvFvZhau5sbCppg3fBwz+YQj/sHT/sHT/sPTjAK8F sZxLkArdjoQZJk+RZEY2TkIuZLZ53BeBOjBvroKO+9OaAUUAJoqs9aVk6cLYYtHnbgaxhIbR kx/SZ2bpRhZ67D4nKzoLvEUuJDYDSGDMaLKxWLaTdta3GXk9f0IW+Vfvx4yRNo88mrxUkJSQ 8M+BMZB7bG+X6SiHPHgbEBKQ90/qGIJgIJm8UCaO8iIH2rSec0l/wxoiXCFHyeQCxUOKAusW OYcavwdMRN/elltAh/MeHhkN5GLFRCkmZxE/VEfZlG2hUCgIDPKbo0lBcUXJezRUKShDNDJk 1c9kBSIvyFDIWALiN9Z11jzNurPoaXqpdo1+55N3a6tW7n9ff6R3aumE50mh8ZcqYoLnVlfE 9N8/oy/PhgsbdsZvB0t23UBx4/UZh4obu1PFNj8bdzg3l6wSZ/1cHzzg7pnel3by5dgv0S1L 745LhzuwvKiVe8zm/FNCZOuEZHqeuXJLfufWywvaTk0xM7joZBPjMK/I/gbscxgQBAQAAA== Cc: "'shane@castlepoint.net'" , "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 06:12:50 -0000 Shahram, Responding to just one of your questions, namely: If I am generating BFD in a central processor, how do I s= end this Link BFD to the desired Link? The answer, IMHO, is "using the same technique that allows the central proce= ssor to send LACP packets via a specific link..." Regards, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Shahr= am Davari [davari@broadcom.com] Sent: Monday, August 01, 2011 7:44 AM To: 'shane@castlepoint.net' Cc: 'rtg-bfd@ietf.org' Subject: Re: Solicit comments on BFD for Interface draft Shane Let's forget about the configuration complexity since we can't agree on it a= nd stick to technical discussions on why I think this draft is a bad idea. First, Could you please explain your protocol layering model. Do we now need= 2 IP layers, one before LAG termination and one after LAG termination, wher= e the one before LAG termination only understands the well known Multicast I= PDA. Or implementing this draft assumes bypassing LAG termination when IP-DA is= the known multicast proposed in the draft. In other words now LAG terminati= on is conditional on IP address. Both are hacky implementation in my opinion. Second, if I am generating BFD in a central processor, how do I send this Li= nk BFD to the desired Link? LAG algorithm will distribute it according to it= s hash function. Doesn't it? Or do we now need to have per Link BFD generato= r? Thanks Shahram ----- Original Message ----- From: Shane Amante [mailto:shane@castlepoint.net] Sent: Sunday, July 31, 2011 07:31 PM To: Shahram Davari Cc: 'rtg-bfd@ietf.org' Subject: Re: Solicit comments on BFD for Interface draft Sharam, On Jul 31, 2011, at 7:12 PM, Shahram Davari wrote: > Hi Shane and all > > Even if as you say BFD requires less configuration (which it doesn't) I noticed you haven't pointed toward an existing standard or, better yet, im= plementation of said standard that would back your claim that today's implem= entations of 802.1ag/Y.1731 are "less configuration" than BFD ... > still it can't justify doing unnecessary layer violation to proxy for Eth= ernet OAM that already exists. Why not use BFD for OTN and PON OAM next. Let's be perfectly clear here. BFD is a fast, failure detection mechanism t= hat is [already] directly integrated into and directly drives *routing* and= *signaling* protocols for IP/MPLS networks. That was why BFD was created a= nd that is how it is being extensively used. And, that's **how** we want to= continue to use it, in this case on component-links of LAG's between /route= d/ devices, as we need to /scale/ our networks beyond the capability of phys= ical media. Ethernet OAM has it's place and will continue to have it's place, but that's= IMO [strictly] in L2 switched networks where one has no other choice (since= those devices are strictly L2 switches), either on: a) Directly adjacent links: 802.3ah or 802.1ag/Y.1731; or, b) Multiple hops: 802.1ag/Y.1731 ... but, Ethernet OAM is a huge pain-in-the-neck to configure and operate, a= s I demonstrated. -shane > Thx > Shahram > > Regards > Shahram > > ----- Original Message ----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Sunday, July 31, 2011 06:00 PM > To: 'shane@castlepoint.net' > Cc: 'rtg-bfd@ietf.org' > Subject: Re: Solicit comments on BFD for Interface draft > > Hi shane > > Same can be said about ethernet oam. Basically everything can be automatic= ally assigned by software except MDL. > > As someone who has implemented OAM and BFD, I can certainly say BFD requir= es more variables and parameters. > > Regards > Shahram > > Regards > Shahram > > ----- Original Message ----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Sunday, July 31, 2011 04:16 PM > To: Shahram Davari > Cc: Bhatia, Manav (Manav) ; rtg-bfd@ietf.= org > Subject: Re: Solicit comments on BFD for Interface draft > > Hi Sharam, > > On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: >> Hi Shane, >> >> Same for BFD. You need to know my discriminator, your discriminator, loca= l IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand mo= de, Authentication, Active/Passive, Detection Interval, etc. > > As an _operator_ of BFD, I am not /required/ to configure every single var= iable you named above, on every single link of every router in my network. = Good try though. > > Not to pick on any one implementation, but here's proof that the only requ= ired **configuration elements** necessary to bring up BFD was the 'minimum-i= nterval', (specifying a period of 100 msecs): > ---snip--- > interface fe-0/0/6.0 { > point-to-point; > bfd-liveness-detection { > minimum-interval 100; > } > } > [...] >> show bfd session > Detect Transmit > Address State Interface Time Interval Multi= plier > 10.200.2.0 Up fe-0/0/6.0 0.300 0.100 3 > > 1 sessions, 1 clients > Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps > ---snip--- > > As with most IETF protocols, and particularly with smart & clever implemen= ters designing & coding them, very sensible defaults are chosen so as to red= uce the configuration burden on behalf of operators. This is another way of= saying, yes, as a [BFD] protocol implementer you need to worry that you've= implemented all of variables required by the RFC, either by forcing the ope= rator to give you input for them or, better yet, by speaking to operators an= d choosing to implement sensible defaults. > > >> Believe me BFD requires more configuration than 802.1ag. So your argument= of requiring a lot of info to configure 802.1ag applies even more to BFD. > > The above would seem to indicate that's false. But, if you still don't be= lieve me, here's a short configuration snippet showing all of the required c= onfiguration parameters to make IEEE 802.1ag work, on just a single link: > ---snip--- > ethernet { > connectivity-fault-management { > maintenance-domain myOrg { > level 1; > name-format character-string; > maintenance-association link-MA { > short-name-format character-string; > continuity-check { > interval 100ms; > } > mep 2 { > interface ge-3/0/1; > direction down; > remote-mep 5; > } > } > } > } > } > ---snip--- > > For starters, as an operator, good luck on trying to keep all your MEP ID'= s straight for every component-link inside every LAG! And, again, I'm not p= icking on any one vendor's configuration syntax ... the above is no differen= t, and sometimes worse, on any other vendor I've configured 802.1ag/Y.1731. > > In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the conc= lusion that the designers of those protocols were likely operating under the= assumption, at that time, that a OSS and/or NMS would be used as the [sole]= means to *configure* and *maintain* all of the configuration elements requi= red to bootstrap them and, when something goes wrong, figure out what inform= ation is being reported by those protocols. Unfortunately, this is complete= ly *untrue* of how we run IP/MPLS networks -- namely, we don't use NMS syste= ms, particularly to configure our networks!, and thus we need something simp= le, that just works, i.e.: BFD. > > -shane > > > >> >> Regards >> Shahram >> >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Shane Amante >> Sent: Saturday, July 30, 2011 9:36 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >> >> Manav, Sharam, Others, >> >> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>> I think the diagnoses is correct, but the medicine isn't! :-) >>> >>> I completely agree that LACP is not fast enough and that operators also= want to detect individual component link breakdowns instead of the entire L= AG. If that's the case then folks should use IEEE 802.1ag for individual com= ponent links and BFD for the entire LAG. Are we trying to position BFD as an= IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over comp= onent links since not all links may be ethernet? >> >> The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731= (or 802.3ah) for *fast* detection of component-link failures in a LAG is: o= perational simplicity, clear and simple. >> >> The problem with 802.1ag/Y.1731 is the massive amount of, potentially err= or-prone, configuration required. Take a moment and think about how many va= riables are *required* to properly set-up 802.1ag/Y.1731: >> a) What MD "name" should you use? >> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >> c) What MD "level" should you use, (probably 0 or 1)? >> d) What MEP ID's do I assign to each side of the link? >> e) Don't forget to configure the right direction, up or down, for the ME= P? >> ... that is *ridiculous*! >> >> Let's not forget that there are [potentially] 100's if not 1,000's of LAG= 's in each carrier's network, so this needs to get repeated over and over an= d over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up *a= nd* maintain. >> >> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx}= interval". (The "multiplier" should default to 3, unless you want to confi= gure it differently). That's it! Done! >> >> So, in short, let me throw my hat in the ring with other operators that I= really, really, really want a standards-based way of running BFD over compo= nent-links in a LAG in order to quickly detect a component-link failure and= take it out of the bundle. >> >> Thanks, >> >> -shane >> >> >> >>> I think (and this is also what Shahram was alluding to) that BFD is mean= t to detect IP liveliness. This means that if I run BFD over an IP interface= it should bring it down only when the IP connectivity goes down. Shouldn't= BFD be oblivious to the number of links alive in a LAG as long as the LAG r= emains up and it can reach the other end. It is a simple implementation effo= rt to note the status of each component link of a lag and to bring it down i= f the number goes below a certain threshold - You don't need to run BFD over= each link! >>> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>> Sent: Saturday, July 30, 2011 3:34 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>> >>>> Hello Manav, >>>> >>>> others have already replied but the part "[...] has no >>>> business" triggers now my reply. I deliberately >>>> "mis"-understand it. Point is that this is about business. >>>> Customers have pushed their vendors to implement BFD over LAG >>>> component links. Reasons I know >>>> >>>> - LACP is not fast enough >>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>> Designers and Operations, so they would like to use it everywhere >>>> - BFDs reputation for being fast and working >>>> >>>> >>>> So now we have 3-4 different implementation for >>>> per-cmponent-link BFD that I know about. Potentially there >>>> exists more. Probably not that much different but enough to >>>> make interoperability impossible. It's again customers who >>>> push now for standardization. Thus the draft to find an agreement :-) >>>> >>>> Will there be only one solution for "BFD over LAG"? Not sure >>>> as I see two fundamental setups: (a) run BFD on every >>>> component link and (b) run a single BFD session over the LAG >>>> interface. They solve different network setups as far as I can see. >>>> >>>> >>>> Regards, Marc >>>> >>>> >>>> >>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>> >>>>> Hi Jeff, >>>>> >>>>> Let me understand this. If you have an IP interface over a >>>> LAG with 5 component links, then you internally establish 5 >>>> BFD sessions with 30ms timeouts? >>>>> >>>>> You don't need to do this. You could use LACP for lag and >>>> BFD for IP connectivity - which means BFD should remain up as >>>> long as there is reachability over the lag. IMO it has no >>>> business to bother with each individual component links. >>>>> >>>>> Cheers, Manav >>>>> >>>>> -----Original Message----- >>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>> >>>>> Hi, >>>>> >>>>> We have been supporting this mode of BFD over LAG >>>> operations for last 5 years and our customers love it. >>>>> >>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>> hit min-links, do you really want to bring the LAG down? >>>>> >>>>> Mach - be aware of patents :) >>>>> >>>>> Regards, >>>>> Jeff >>>>> >>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>> wrote: >>>>> >>>>>> Hi Mach, >>>>>> >>>>>> I am not sure I understand why you would want BFD to >>>> ensure liveliness of each component link in a LAG. The draft >>>> seems to suggest establishing separate BFD session for each >>>> pair of component interfaces to detect the failures. Why >>>> should BFD be concerned about each component link? I would >>>> rather that BFD sprays packets over each component link in a >>>> round robin fashion and brings down the IP interface over a >>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>> -----Original Message----- >>>>>> From: rtg-bfd-bounces@ietf.org >>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>> Behalf Of Mach Chen >>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>> To: rtg-bfd@ietf.org >>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>> >>>>>> Hi, >>>>>> >>>>>> We uploaded a new >>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>> that is about BFD running over interface(e.g., LAG/Bundle >>>> interface). You are very welcome to read the draft and give >>>> your comments. >>>>>> >>>>>> Many thanks, >>>>>> Mach >>>>> >>>> >>>> -- >>>> Marc Binderberger >>>> >>>> >> >> >> > > > > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From mach.chen@huawei.com Sun Jul 31 23:33:10 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B7B21F86C0 for ; Sun, 31 Jul 2011 23:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=-3.595, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLfcI9eo1z3e for ; Sun, 31 Jul 2011 23:33:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95121F8666 for ; Sun, 31 Jul 2011 23:33:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800AHBKTJJA@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 14:32:08 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800FQOKR32Q@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 14:32:07 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACU32876; Mon, 01 Aug 2011 14:32:06 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 01 Aug 2011 14:32:05 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Mon, 01 Aug 2011 14:32:06 +0800 Date: Mon, 01 Aug 2011 06:32:05 +0000 From: Mach Chen Subject: =?gb2312?B?tPC4tDogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBk?= =?gb2312?Q?raft?= In-reply-to: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.com> X-Originating-IP: [172.24.2.41] To: Shahram Davari , "'shane@castlepoint.net'" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMTXaSGUO8YfsvQESe7fRUbEFVi5UCgIrw//+AwoCAAAlGgIABSygAgAAZOoCAAR2YAIABcuqAgACPZACAABzigIAAA0OAgAAWUICAACUCAIAAnKsS X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.com> Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 06:33:10 -0000 SGkgU2hhaHJhbSwNCg0KUGxlYXNlIHNlZSBteSByZXBvbnNlIGlubGluZSB3aXRoIFtNYWNoXS4u Li4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogcnRn LWJmZC1ib3VuY2VzQGlldGYub3JnIFtydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gU2hh aHJhbSBEYXZhcmkgW2RhdmFyaUBicm9hZGNvbS5jb21dDQq3osvNyrG85DogMjAxMcTqONTCMcjV IDEyOjQ0DQq1vTogJ3NoYW5lQGNhc3RsZXBvaW50Lm5ldCcNCkNjOiAncnRnLWJmZEBpZXRmLm9y ZycNCtb3zOI6IFJlOiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0 DQoNClNoYW5lDQoNCkxldCdzIGZvcmdldCBhYm91dCB0aGUgY29uZmlndXJhdGlvbiBjb21wbGV4 aXR5IHNpbmNlIHdlIGNhbid0IGFncmVlIG9uIGl0IGFuZCBzdGljayB0byB0ZWNobmljYWwgZGlz Y3Vzc2lvbnMgb24gd2h5IEkgdGhpbmsgdGhpcyBkcmFmdCAgaXMgYSBiYWQgaWRlYS4NCg0KRmly c3QsIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB5b3VyIHByb3RvY29sIGxheWVyaW5nIG1vZGVs LiBEbyB3ZSBub3cgbmVlZCAyIElQIGxheWVycywgb25lIGJlZm9yZSBMQUcgdGVybWluYXRpb24g YW5kIG9uZSBhZnRlciBMQUcgdGVybWluYXRpb24sIHdoZXJlIHRoZSBvbmUgYmVmb3JlIExBRyB0 ZXJtaW5hdGlvbiBvbmx5IHVuZGVyc3RhbmRzIHRoZSB3ZWxsIGtub3duIE11bHRpY2FzdCBJUERB Lg0KDQpPciBpbXBsZW1lbnRpbmcgdGhpcyBkcmFmdCBhc3N1bWVzICBieXBhc3NpbmcgTEFHIHRl cm1pbmF0aW9uIHdoZW4gSVAtREEgaXMgdGhlIGtub3duIG11bHRpY2FzdCBwcm9wb3NlZCBpbiB0 aGUgZHJhZnQuIEluIG90aGVyIHdvcmRzIG5vdyBMQUcgdGVybWluYXRpb24gaXMgY29uZGl0aW9u YWwgb24gSVAgYWRkcmVzcy4NCg0KW01hY2hdIEZyb20gdGhlIHZpZXcgb2YgaW1wbGVtZW50YXRp b24sIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBydW5pbmcgc2luZ2xlIEJGRCBvdmVy IGEgTEFHIGFuZCBydW5pbmcgcGVyLWxpbmsgQkZELiBUaGUga2V5IHBvaW50IGlzIGhvdyB0byBp ZGVudGlmeSBhIEJGRCBwYWNrZXQsIGN1cnJlbnQgYXMgZGVmaW5lZCBpbiBSRkMgNTg4MCwgaXQg dXNlcyB0aGUgVURQIHBvcnQsIG5vdyBmb3IgcGVyLWxpbmsgQkZELCBpdCB1c2VzIGJvdGggbXVs dGljYXN0IElQIERBIGFuZCBVRFAgcG9ydC4gWW91IGNhbiBkbyBpdCBiZWZvcmUgb3IgYWZ0ZXIg dGhlIExBRyB0ZXJtaW5hdGlvbiwgaXQncyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCg0KW10N Cg0KQm90aCBhcmUgaGFja3kgaW1wbGVtZW50YXRpb24gaW4gbXkgb3Bpbmlvbi4NCg0KU2Vjb25k LCBpZiBJIGFtIGdlbmVyYXRpbmcgQkZEIGluIGEgY2VudHJhbCBwcm9jZXNzb3IsIGhvdyBkbyBJ IHNlbmQgdGhpcyBMaW5rIEJGRCB0byB0aGUgZGVzaXJlZCBMaW5rPyBMQUcgYWxnb3JpdGhtIHdp bGwgZGlzdHJpYnV0ZSBpdCBhY2NvcmRpbmcgdG8gaXRzIGhhc2ggZnVuY3Rpb24uIERvZXNuJ3Qg aXQ/IE9yIGRvIHdlIG5vdyBuZWVkIHRvIGhhdmUgcGVyIExpbmsgQkZEIGdlbmVyYXRvcj8NCg0K W01hY2hdIFdoZW4gdGhlIEJGRCBzZXNzaW9ucyBlc3RhYmxpc2hlZCwgdGhlcmUgc2hvdWxkIGJl IG1hcHBpbmcgaW5mb3JtYXRpb24gb2YgdGhlIGxpbmtzIHRvIHRoZSBzcGVjaWZpYyBzZXNzaW9u cyBpbiB0aGUgc3lzdGVtLCB5b3UgYXJlIGZyZWUgdG8gdXNlIHRoZW0uIFRoZXJlIGFyZSBtYW55 IHdheXMgdG8gYWNoaWV2ZSB0aGlzIGFuZCBwZXIgTGluayBCRkQgZ2VuZXJhdG9yIGlzIGp1c3Qg b25lIG9mIHRoZW0uDQoNClRoYW5rcw0KU2hhaHJhbQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQpGcm9tOiBTaGFuZSBBbWFudGUgW21haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXRd DQpTZW50OiBTdW5kYXksIEp1bHkgMzEsIDIwMTEgMDc6MzEgUE0NClRvOiBTaGFocmFtIERhdmFy aQ0KQ2M6ICdydGctYmZkQGlldGYub3JnJyA8cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0DQoNClNoYXJhbSwN Cg0KT24gSnVsIDMxLCAyMDExLCBhdCA3OjEyIFBNLCBTaGFocmFtIERhdmFyaSB3cm90ZToNCj4g SGkgU2hhbmUgYW5kIGFsbA0KPg0KPiBFdmVuIGlmIGFzIHlvdSBzYXkgQkZEIHJlcXVpcmVzIGxl c3MgY29uZmlndXJhdGlvbiAod2hpY2ggaXQgZG9lc24ndCkNCg0KSSBub3RpY2VkIHlvdSBoYXZl bid0IHBvaW50ZWQgdG93YXJkIGFuIGV4aXN0aW5nIHN0YW5kYXJkIG9yLCBiZXR0ZXIgeWV0LCBp bXBsZW1lbnRhdGlvbiBvZiBzYWlkIHN0YW5kYXJkIHRoYXQgd291bGQgYmFjayB5b3VyIGNsYWlt IHRoYXQgdG9kYXkncyBpbXBsZW1lbnRhdGlvbnMgb2YgODAyLjFhZy9ZLjE3MzEgYXJlICJsZXNz IGNvbmZpZ3VyYXRpb24iIHRoYW4gQkZEIC4uLg0KDQoNCj4gc3RpbGwgaXQgY2FuJ3QganVzdGlm eSBkb2luZyB1bm5lY2Vzc2FyeSAgbGF5ZXIgdmlvbGF0aW9uIHRvIHByb3h5IGZvciBFdGhlcm5l dCBPQU0gdGhhdCBhbHJlYWR5IGV4aXN0cy4gV2h5IG5vdCB1c2UgQkZEIGZvciBPVE4gYW5kIFBP TiBPQU0gbmV4dC4NCg0KTGV0J3MgYmUgcGVyZmVjdGx5IGNsZWFyIGhlcmUuICBCRkQgaXMgYSBm YXN0LCBmYWlsdXJlIGRldGVjdGlvbiBtZWNoYW5pc20gdGhhdCBpcyBbYWxyZWFkeV0gZGlyZWN0 bHkgaW50ZWdyYXRlZCBpbnRvIGFuZCBkaXJlY3RseSBkcml2ZXMgKnJvdXRpbmcqIGFuZCAqc2ln bmFsaW5nKiBwcm90b2NvbHMgZm9yIElQL01QTFMgbmV0d29ya3MuICBUaGF0IHdhcyB3aHkgQkZE IHdhcyBjcmVhdGVkIGFuZCB0aGF0IGlzIGhvdyBpdCBpcyBiZWluZyBleHRlbnNpdmVseSB1c2Vk LiAgQW5kLCB0aGF0J3MgKipob3cqKiB3ZSB3YW50IHRvIGNvbnRpbnVlIHRvIHVzZSBpdCwgaW4g dGhpcyBjYXNlIG9uIGNvbXBvbmVudC1saW5rcyBvZiBMQUcncyBiZXR3ZWVuIC9yb3V0ZWQvIGRl dmljZXMsIGFzIHdlIG5lZWQgdG8gL3NjYWxlLyBvdXIgbmV0d29ya3MgYmV5b25kIHRoZSBjYXBh YmlsaXR5IG9mIHBoeXNpY2FsIG1lZGlhLg0KDQpFdGhlcm5ldCBPQU0gaGFzIGl0J3MgcGxhY2Ug YW5kIHdpbGwgY29udGludWUgdG8gaGF2ZSBpdCdzIHBsYWNlLCBidXQgdGhhdCdzIElNTyBbc3Ry aWN0bHldIGluIEwyIHN3aXRjaGVkIG5ldHdvcmtzIHdoZXJlIG9uZSBoYXMgbm8gb3RoZXIgY2hv aWNlIChzaW5jZSB0aG9zZSBkZXZpY2VzIGFyZSBzdHJpY3RseSBMMiBzd2l0Y2hlcyksIGVpdGhl ciBvbjoNCmEpICBEaXJlY3RseSBhZGphY2VudCBsaW5rczogODAyLjNhaCBvciA4MDIuMWFnL1ku MTczMTsgb3IsDQpiKSAgTXVsdGlwbGUgaG9wczogODAyLjFhZy9ZLjE3MzENCi4uLiBidXQsIEV0 aGVybmV0IE9BTSBpcyBhIGh1Z2UgcGFpbi1pbi10aGUtbmVjayB0byBjb25maWd1cmUgYW5kIG9w ZXJhdGUsIGFzIEkgZGVtb25zdHJhdGVkLg0KDQotc2hhbmUNCg0KDQo+IFRoeA0KPiBTaGFocmFt DQo+DQo+IFJlZ2FyZHMNCj4gU2hhaHJhbQ0KPg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQo+IEZyb206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbV0N Cj4gU2VudDogU3VuZGF5LCBKdWx5IDMxLCAyMDExIDA2OjAwIFBNDQo+IFRvOiAnc2hhbmVAY2Fz dGxlcG9pbnQubmV0JyA8c2hhbmVAY2FzdGxlcG9pbnQubmV0Pg0KPiBDYzogJ3J0Zy1iZmRAaWV0 Zi5vcmcnIDxydGctYmZkQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogU29saWNpdCBjb21tZW50 cyBvbiBCRkQgZm9yIEludGVyZmFjZSBkcmFmdA0KPg0KPiBIaSBzaGFuZQ0KPg0KPiBTYW1lIGNh biBiZSBzYWlkIGFib3V0IGV0aGVybmV0IG9hbS4gQmFzaWNhbGx5IGV2ZXJ5dGhpbmcgY2FuIGJl IGF1dG9tYXRpY2FsbHkgYXNzaWduZWQgYnkgc29mdHdhcmUgZXhjZXB0IE1ETC4NCj4NCj4gQXMg c29tZW9uZSB3aG8gaGFzIGltcGxlbWVudGVkIE9BTSBhbmQgQkZELCBJIGNhbiBjZXJ0YWlubHkg c2F5IEJGRCByZXF1aXJlcyBtb3JlIHZhcmlhYmxlcyBhbmQgcGFyYW1ldGVycy4NCj4NCj4gUmVn YXJkcw0KPiBTaGFocmFtDQo+DQo+IFJlZ2FyZHMNCj4gU2hhaHJhbQ0KPg0KPiAtLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNh c3RsZXBvaW50Lm5ldF0NCj4gU2VudDogU3VuZGF5LCBKdWx5IDMxLCAyMDExIDA0OjE2IFBNDQo+ IFRvOiBTaGFocmFtIERhdmFyaQ0KPiBDYzogQmhhdGlhLCBNYW5hdiAoTWFuYXYpIDxtYW5hdi5i aGF0aWFAYWxjYXRlbC1sdWNlbnQuY29tPjsgcnRnLWJmZEBpZXRmLm9yZyA8cnRnLWJmZEBpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFNvbGljaXQgY29tbWVudHMgb24gQkZEIGZvciBJbnRlcmZh Y2UgZHJhZnQNCj4NCj4gSGkgU2hhcmFtLA0KPg0KPiBPbiBKdWwgMzEsIDIwMTEsIGF0IDg6NDMg QU0sIFNoYWhyYW0gRGF2YXJpIHdyb3RlOg0KPj4gSGkgU2hhbmUsDQo+Pg0KPj4gU2FtZSBmb3Ig QkZELiBZb3UgbmVlZCB0byBrbm93IG15IGRpc2NyaW1pbmF0b3IsIHlvdXIgZGlzY3JpbWluYXRv ciwgbG9jYWwgSVAgYWRkcmVzcywgcmVtb3RlIElQIGFkZHJlc3MsIE1pbiBUeCBJbnRlcnZhbCwg TWluIFJ4IEludGVydmFsLCBEZW1hbmQgbW9kZSwgQXV0aGVudGljYXRpb24sIEFjdGl2ZS9QYXNz aXZlLCBEZXRlY3Rpb24gSW50ZXJ2YWwsIGV0Yy4NCj4NCj4gQXMgYW4gX29wZXJhdG9yXyBvZiBC RkQsIEkgYW0gbm90IC9yZXF1aXJlZC8gdG8gY29uZmlndXJlIGV2ZXJ5IHNpbmdsZSB2YXJpYWJs ZSB5b3UgbmFtZWQgYWJvdmUsIG9uIGV2ZXJ5IHNpbmdsZSBsaW5rIG9mIGV2ZXJ5IHJvdXRlciBp biBteSBuZXR3b3JrLiAgR29vZCB0cnkgdGhvdWdoLg0KPg0KPiBOb3QgdG8gcGljayBvbiBhbnkg b25lIGltcGxlbWVudGF0aW9uLCBidXQgaGVyZSdzIHByb29mIHRoYXQgdGhlIG9ubHkgcmVxdWly ZWQgKipjb25maWd1cmF0aW9uIGVsZW1lbnRzKiogbmVjZXNzYXJ5IHRvIGJyaW5nIHVwIEJGRCB3 YXMgdGhlICdtaW5pbXVtLWludGVydmFsJywgKHNwZWNpZnlpbmcgYSBwZXJpb2Qgb2YgMTAwIG1z ZWNzKToNCj4gLS0tc25pcC0tLQ0KPiBpbnRlcmZhY2UgZmUtMC8wLzYuMCB7DQo+ICAgIHBvaW50 LXRvLXBvaW50Ow0KPiAgICBiZmQtbGl2ZW5lc3MtZGV0ZWN0aW9uIHsNCj4gICAgICAgIG1pbmlt dW0taW50ZXJ2YWwgMTAwOw0KPiAgICB9DQo+IH0NCj4gWy4uLl0NCj4+IHNob3cgYmZkIHNlc3Np b24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERl dGVjdCAgIFRyYW5zbWl0DQo+IEFkZHJlc3MgICAgICAgICAgICAgICAgICBTdGF0ZSAgICAgSW50 ZXJmYWNlICAgICAgVGltZSAgICAgSW50ZXJ2YWwgIE11bHRpcGxpZXINCj4gMTAuMjAwLjIuMCAg ICAgICAgICAgICAgIFVwICAgICAgICBmZS0wLzAvNi4wICAgICAwLjMwMCAgICAgMC4xMDAgICAg ICAgIDMNCj4NCj4gMSBzZXNzaW9ucywgMSBjbGllbnRzDQo+IEN1bXVsYXRpdmUgdHJhbnNtaXQg cmF0ZSAxMC4wIHBwcywgY3VtdWxhdGl2ZSByZWNlaXZlIHJhdGUgMTAuMCBwcHMNCj4gLS0tc25p cC0tLQ0KPg0KPiBBcyB3aXRoIG1vc3QgSUVURiBwcm90b2NvbHMsIGFuZCBwYXJ0aWN1bGFybHkg d2l0aCBzbWFydCAmIGNsZXZlciBpbXBsZW1lbnRlcnMgZGVzaWduaW5nICYgY29kaW5nIHRoZW0s IHZlcnkgc2Vuc2libGUgZGVmYXVsdHMgYXJlIGNob3NlbiBzbyBhcyB0byByZWR1Y2UgdGhlIGNv bmZpZ3VyYXRpb24gYnVyZGVuIG9uIGJlaGFsZiBvZiBvcGVyYXRvcnMuICBUaGlzIGlzIGFub3Ro ZXIgd2F5IG9mIHNheWluZywgeWVzLCBhcyBhIFtCRkRdIHByb3RvY29sIGltcGxlbWVudGVyIHlv dSBuZWVkIHRvIHdvcnJ5IHRoYXQgeW91J3ZlIGltcGxlbWVudGVkIGFsbCBvZiB2YXJpYWJsZXMg cmVxdWlyZWQgYnkgdGhlIFJGQywgZWl0aGVyIGJ5IGZvcmNpbmcgdGhlIG9wZXJhdG9yIHRvIGdp dmUgeW91IGlucHV0IGZvciB0aGVtIG9yLCBiZXR0ZXIgeWV0LCBieSBzcGVha2luZyB0byBvcGVy YXRvcnMgYW5kIGNob29zaW5nIHRvIGltcGxlbWVudCBzZW5zaWJsZSBkZWZhdWx0cy4NCj4NCj4N Cj4+IEJlbGlldmUgbWUgQkZEIHJlcXVpcmVzIG1vcmUgY29uZmlndXJhdGlvbiB0aGFuIDgwMi4x YWcuIFNvIHlvdXIgYXJndW1lbnQgb2YgcmVxdWlyaW5nIGEgbG90IG9mIGluZm8gdG8gY29uZmln dXJlIDgwMi4xYWcgYXBwbGllcyBldmVuIG1vcmUgdG8gQkZELg0KPg0KPiBUaGUgYWJvdmUgd291 bGQgc2VlbSB0byBpbmRpY2F0ZSB0aGF0J3MgZmFsc2UuICBCdXQsIGlmIHlvdSBzdGlsbCBkb24n dCBiZWxpZXZlIG1lLCBoZXJlJ3MgYSBzaG9ydCBjb25maWd1cmF0aW9uIHNuaXBwZXQgc2hvd2lu ZyBhbGwgb2YgdGhlIHJlcXVpcmVkIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyB0byBtYWtlIElF RUUgODAyLjFhZyB3b3JrLCBvbiBqdXN0IGEgc2luZ2xlIGxpbms6DQo+IC0tLXNuaXAtLS0NCj4g ZXRoZXJuZXQgew0KPiAgICBjb25uZWN0aXZpdHktZmF1bHQtbWFuYWdlbWVudCB7DQo+ICAgICAg ICBtYWludGVuYW5jZS1kb21haW4gbXlPcmcgew0KPiAgICAgICAgICAgIGxldmVsIDE7DQo+ICAg ICAgICAgICAgbmFtZS1mb3JtYXQgY2hhcmFjdGVyLXN0cmluZzsNCj4gICAgICAgICAgICBtYWlu dGVuYW5jZS1hc3NvY2lhdGlvbiBsaW5rLU1BIHsNCj4gICAgICAgICAgICAgICAgc2hvcnQtbmFt ZS1mb3JtYXQgY2hhcmFjdGVyLXN0cmluZzsNCj4gICAgICAgICAgICAgICAgY29udGludWl0eS1j aGVjayB7DQo+ICAgICAgICAgICAgICAgICAgICBpbnRlcnZhbCAxMDBtczsNCj4gICAgICAgICAg ICAgICAgfQ0KPiAgICAgICAgICAgICAgICBtZXAgMiB7DQo+ICAgICAgICAgICAgICAgICAgICBp bnRlcmZhY2UgZ2UtMy8wLzE7DQo+ICAgICAgICAgICAgICAgICAgICBkaXJlY3Rpb24gZG93bjsN Cj4gICAgICAgICAgICAgICAgICAgIHJlbW90ZS1tZXAgNTsNCj4gICAgICAgICAgICAgICAgfQ0K PiAgICAgICAgICAgIH0NCj4gICAgICAgIH0NCj4gICAgfQ0KPiB9DQo+IC0tLXNuaXAtLS0NCj4N Cj4gRm9yIHN0YXJ0ZXJzLCBhcyBhbiBvcGVyYXRvciwgZ29vZCBsdWNrIG9uIHRyeWluZyB0byBr ZWVwIGFsbCB5b3VyIE1FUCBJRCdzIHN0cmFpZ2h0IGZvciBldmVyeSBjb21wb25lbnQtbGluayBp bnNpZGUgZXZlcnkgTEFHISAgQW5kLCBhZ2FpbiwgSSdtIG5vdCBwaWNraW5nIG9uIGFueSBvbmUg dmVuZG9yJ3MgY29uZmlndXJhdGlvbiBzeW50YXggLi4uIHRoZSBhYm92ZSBpcyBubyBkaWZmZXJl bnQsIGFuZCBzb21ldGltZXMgd29yc2UsIG9uIGFueSBvdGhlciB2ZW5kb3IgSSd2ZSBjb25maWd1 cmVkIDgwMi4xYWcvWS4xNzMxLg0KPg0KPiBJbiBzdW1tYXJ5LCBhcyBJJ3ZlIHN0dWRpZWQgSUVF RSA4MDIuMWFnL0lUVSBZLjE3MzEsIEkndmUgY29tZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IHRo ZSBkZXNpZ25lcnMgb2YgdGhvc2UgcHJvdG9jb2xzIHdlcmUgbGlrZWx5IG9wZXJhdGluZyB1bmRl ciB0aGUgYXNzdW1wdGlvbiwgYXQgdGhhdCB0aW1lLCB0aGF0IGEgT1NTIGFuZC9vciBOTVMgd291 bGQgYmUgdXNlZCBhcyB0aGUgW3NvbGVdIG1lYW5zIHRvICpjb25maWd1cmUqIGFuZCAqbWFpbnRh aW4qIGFsbCBvZiB0aGUgY29uZmlndXJhdGlvbiBlbGVtZW50cyByZXF1aXJlZCB0byBib290c3Ry YXAgdGhlbSBhbmQsIHdoZW4gc29tZXRoaW5nIGdvZXMgd3JvbmcsIGZpZ3VyZSBvdXQgd2hhdCBp bmZvcm1hdGlvbiBpcyBiZWluZyByZXBvcnRlZCBieSB0aG9zZSBwcm90b2NvbHMuICBVbmZvcnR1 bmF0ZWx5LCB0aGlzIGlzIGNvbXBsZXRlbHkgKnVudHJ1ZSogb2YgaG93IHdlIHJ1biBJUC9NUExT IG5ldHdvcmtzIC0tIG5hbWVseSwgd2UgZG9uJ3QgdXNlIE5NUyBzeXN0ZW1zLCBwYXJ0aWN1bGFy bHkgdG8gY29uZmlndXJlIG91ciBuZXR3b3JrcyEsIGFuZCB0aHVzIHdlIG5lZWQgc29tZXRoaW5n IHNpbXBsZSwgdGhhdCBqdXN0IHdvcmtzLCBpLmUuOiBCRkQuDQo+DQo+IC1zaGFuZQ0KPg0KPg0K Pg0KPj4NCj4+IFJlZ2FyZHMNCj4+IFNoYWhyYW0NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnLWJm ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hhbmUgQW1hbnRlDQo+PiBTZW50OiBT YXR1cmRheSwgSnVseSAzMCwgMjAxMSA5OjM2IEFNDQo+PiBUbzogQmhhdGlhLCBNYW5hdiAoTWFu YXYpDQo+PiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFNvbGljaXQgY29t bWVudHMgb24gQkZEIGZvciBJbnRlcmZhY2UgZHJhZnQNCj4+DQo+PiBNYW5hdiwgU2hhcmFtLCBP dGhlcnMsDQo+Pg0KPj4gT24gSnVsIDI5LCAyMDExLCBhdCA1OjM0IFBNLCBCaGF0aWEsIE1hbmF2 IChNYW5hdikgd3JvdGU6DQo+Pj4gSSB0aGluayB0aGUgZGlhZ25vc2VzIGlzIGNvcnJlY3QsIGJ1 dCB0aGUgbWVkaWNpbmUgaXNuJ3QhIDotKQ0KPj4+DQo+Pj4gSSBjb21wbGV0ZWx5IGFncmVlIHRo YXQgTEFDUCBpcyBub3QgZmFzdCBlbm91Z2ggYW5kIHRoYXQgb3BlcmF0b3JzIGFsc28gd2FudCB0 byBkZXRlY3QgaW5kaXZpZHVhbCBjb21wb25lbnQgbGluayBicmVha2Rvd25zIGluc3RlYWQgb2Yg dGhlIGVudGlyZSBMQUcuIElmIHRoYXQncyB0aGUgY2FzZSB0aGVuIGZvbGtzIHNob3VsZCB1c2Ug SUVFRSA4MDIuMWFnIGZvciBpbmRpdmlkdWFsIGNvbXBvbmVudCBsaW5rcyBhbmQgQkZEIGZvciB0 aGUgZW50aXJlIExBRy4gQXJlIHdlIHRyeWluZyB0byBwb3NpdGlvbiBCRkQgYXMgYW4gSUVURiBl cXVpdmFsZW50IG9mIDgwMi4xYWc/IE9yIGlzIGl0IHRoYXQgd2UncmUgdHJ5aW5nIHRvIHJ1biBC RkQgb3ZlciBjb21wb25lbnQgbGlua3Mgc2luY2Ugbm90IGFsbCBsaW5rcyBtYXkgYmUgZXRoZXJu ZXQ/DQo+Pg0KPj4gVGhlIG1haW4gcmVhc29uICh3ZSkgb3BlcmF0b3JzIHdhbnQgdG8gdXNlIEJG RCBpbnN0ZWFkIG9mIDgwMi4xYWcvWS4xNzMxIChvciA4MDIuM2FoKSBmb3IgKmZhc3QqIGRldGVj dGlvbiBvZiBjb21wb25lbnQtbGluayBmYWlsdXJlcyBpbiBhIExBRyBpczogb3BlcmF0aW9uYWwg c2ltcGxpY2l0eSwgY2xlYXIgYW5kIHNpbXBsZS4NCj4+DQo+PiBUaGUgcHJvYmxlbSB3aXRoIDgw Mi4xYWcvWS4xNzMxIGlzIHRoZSBtYXNzaXZlIGFtb3VudCBvZiwgcG90ZW50aWFsbHkgZXJyb3It cHJvbmUsIGNvbmZpZ3VyYXRpb24gcmVxdWlyZWQuICBUYWtlIGEgbW9tZW50IGFuZCB0aGluayBh Ym91dCBob3cgbWFueSB2YXJpYWJsZXMgYXJlICpyZXF1aXJlZCogdG8gcHJvcGVybHkgc2V0LXVw IDgwMi4xYWcvWS4xNzMxOg0KPj4gYSkgIFdoYXQgTUQgIm5hbWUiIHNob3VsZCB5b3UgdXNlPw0K Pj4gYikgIFdoYXQgTUQgIm5hbWUgZm9ybWF0IiBzaG91bGQgeW91IHVzZSwgKEFTQ0lJLCBETlMs IGV0Yy4pPw0KPj4gYykgIFdoYXQgTUQgImxldmVsIiBzaG91bGQgeW91IHVzZSwgKHByb2JhYmx5 IDAgb3IgMSk/DQo+PiBkKSAgV2hhdCBNRVAgSUQncyBkbyBJIGFzc2lnbiB0byBlYWNoIHNpZGUg b2YgdGhlIGxpbms/DQo+PiBlKSAgRG9uJ3QgZm9yZ2V0IHRvIGNvbmZpZ3VyZSB0aGUgcmlnaHQg ZGlyZWN0aW9uLCB1cCBvciBkb3duLCBmb3IgdGhlIE1FUD8NCj4+IC4uLiB0aGF0IGlzICpyaWRp Y3Vsb3VzKiENCj4+DQo+PiBMZXQncyBub3QgZm9yZ2V0IHRoYXQgdGhlcmUgYXJlIFtwb3RlbnRp YWxseV0gMTAwJ3MgaWYgbm90IDEsMDAwJ3Mgb2YgTEFHJ3MgaW4gZWFjaCBjYXJyaWVyJ3MgbmV0 d29yaywgc28gdGhpcyBuZWVkcyB0byBnZXQgcmVwZWF0ZWQgb3ZlciBhbmQgb3ZlciBhbmQgb3Zl ciBhZ2Fpbi4gIEJvdHRvbS1saW5lOiA4MDIuMWFnL1kuMTczMSBpcyBleHRyZW1lbHkgY29tcGxl eCB0byBzZXQtdXAgKmFuZCogbWFpbnRhaW4uDQo+Pg0KPj4gQkZEIGlzIHNpbXBsZS4gIEF0IGEg YmFyZSBtaW5pbXVtIHlvdSBqdXN0IG5lZWQgdG8gY29uZmlndXJlIGFuICJ7VHh8Unh9IGludGVy dmFsIi4gIChUaGUgIm11bHRpcGxpZXIiIHNob3VsZCBkZWZhdWx0IHRvIDMsIHVubGVzcyB5b3Ug d2FudCB0byBjb25maWd1cmUgaXQgZGlmZmVyZW50bHkpLiBUaGF0J3MgaXQhICBEb25lIQ0KPj4N Cj4+IFNvLCBpbiBzaG9ydCwgbGV0IG1lIHRocm93IG15IGhhdCBpbiB0aGUgcmluZyB3aXRoIG90 aGVyIG9wZXJhdG9ycyB0aGF0IEkgcmVhbGx5LCByZWFsbHksIHJlYWxseSB3YW50IGEgc3RhbmRh cmRzLWJhc2VkIHdheSBvZiBydW5uaW5nIEJGRCBvdmVyIGNvbXBvbmVudC1saW5rcyBpbiBhIExB RyBpbiBvcmRlciB0byBxdWlja2x5IGRldGVjdCBhIGNvbXBvbmVudC1saW5rIGZhaWx1cmUgYW5k IHRha2UgaXQgb3V0IG9mIHRoZSBidW5kbGUuDQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+IC1zaGFu ZQ0KPj4NCj4+DQo+Pg0KPj4+IEkgdGhpbmsgKGFuZCB0aGlzIGlzIGFsc28gd2hhdCBTaGFocmFt IHdhcyBhbGx1ZGluZyB0bykgdGhhdCBCRkQgaXMgbWVhbnQgdG8gZGV0ZWN0IElQIGxpdmVsaW5l c3MuIFRoaXMgbWVhbnMgdGhhdCBpZiBJIHJ1biBCRkQgb3ZlciBhbiBJUCBpbnRlcmZhY2UgaXQg c2hvdWxkIGJyaW5nIGl0IGRvd24gb25seSB3aGVuIHRoZSBJUCBjb25uZWN0aXZpdHkgZ29lcyBk b3duLiBTaG91bGRuJ3QgQkZEIGJlIG9ibGl2aW91cyB0byB0aGUgbnVtYmVyIG9mIGxpbmtzIGFs aXZlIGluIGEgTEFHIGFzIGxvbmcgYXMgdGhlIExBRyByZW1haW5zIHVwIGFuZCBpdCBjYW4gcmVh Y2ggdGhlIG90aGVyIGVuZC4gSXQgaXMgYSBzaW1wbGUgaW1wbGVtZW50YXRpb24gZWZmb3J0IHRv IG5vdGUgdGhlIHN0YXR1cyBvZiBlYWNoIGNvbXBvbmVudCBsaW5rIG9mIGEgbGFnIGFuZCB0byBi cmluZyBpdCBkb3duIGlmIHRoZSBudW1iZXIgZ29lcyBiZWxvdyBhIGNlcnRhaW4gdGhyZXNob2xk IC0gWW91IGRvbid0IG5lZWQgdG8gcnVuIEJGRCBvdmVyIGVhY2ggbGluayENCj4+Pg0KPj4+IENo ZWVycywgTWFuYXYNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBG cm9tOiBNYXJjIEJpbmRlcmJlcmdlciBbbWFpbHRvOm1hcmNAc25pZmYuZGVdDQo+Pj4+IFNlbnQ6 IFNhdHVyZGF5LCBKdWx5IDMwLCAyMDExIDM6MzQgQU0NCj4+Pj4gVG86IEJoYXRpYSwgTWFuYXYg KE1hbmF2KQ0KPj4+PiBDYzogSmVmZiBUYW50c3VyYTsgcnRnLWJmZEBpZXRmLm9yZw0KPj4+PiBT dWJqZWN0OiBSZTogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBkcmFmdA0K Pj4+Pg0KPj4+PiBIZWxsbyBNYW5hdiwNCj4+Pj4NCj4+Pj4gb3RoZXJzIGhhdmUgYWxyZWFkeSBy ZXBsaWVkIGJ1dCB0aGUgcGFydCAiWy4uLl0gaGFzIG5vDQo+Pj4+IGJ1c2luZXNzIiB0cmlnZ2Vy cyBub3cgbXkgcmVwbHkuIEkgZGVsaWJlcmF0ZWx5DQo+Pj4+ICJtaXMiLXVuZGVyc3RhbmQgaXQu IFBvaW50IGlzIHRoYXQgdGhpcyBpcyBhYm91dCBidXNpbmVzcy4NCj4+Pj4gQ3VzdG9tZXJzIGhh dmUgcHVzaGVkIHRoZWlyIHZlbmRvcnMgdG8gaW1wbGVtZW50IEJGRCBvdmVyIExBRw0KPj4+PiBj b21wb25lbnQgbGlua3MuIFJlYXNvbnMgSSBrbm93DQo+Pj4+DQo+Pj4+IC0gTEFDUCBpcyBub3Qg ZmFzdCBlbm91Z2gNCj4+Pj4gLSBCRkQgaW4gaXQncyBJUCBmb3JtIChJUCtVRFArQkZEKSBpcyB1 bmRlcnN0b29kIGJ5IFRlbGNvDQo+Pj4+IERlc2lnbmVycyBhbmQgT3BlcmF0aW9ucywgc28gdGhl eSB3b3VsZCBsaWtlIHRvIHVzZSBpdCBldmVyeXdoZXJlDQo+Pj4+IC0gQkZEcyByZXB1dGF0aW9u IGZvciBiZWluZyBmYXN0IGFuZCB3b3JraW5nDQo+Pj4+DQo+Pj4+DQo+Pj4+IFNvIG5vdyB3ZSBo YXZlIDMtNCBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb24gZm9yDQo+Pj4+IHBlci1jbXBvbmVudC1s aW5rIEJGRCB0aGF0IEkga25vdyBhYm91dC4gUG90ZW50aWFsbHkgdGhlcmUNCj4+Pj4gZXhpc3Rz IG1vcmUuIFByb2JhYmx5IG5vdCB0aGF0IG11Y2ggZGlmZmVyZW50IGJ1dCBlbm91Z2ggdG8NCj4+ Pj4gbWFrZSBpbnRlcm9wZXJhYmlsaXR5IGltcG9zc2libGUuIEl0J3MgYWdhaW4gY3VzdG9tZXJz IHdobw0KPj4+PiBwdXNoIG5vdyBmb3Igc3RhbmRhcmRpemF0aW9uLiBUaHVzIHRoZSBkcmFmdCB0 byBmaW5kIGFuIGFncmVlbWVudCA6LSkNCj4+Pj4NCj4+Pj4gV2lsbCB0aGVyZSBiZSBvbmx5IG9u ZSBzb2x1dGlvbiBmb3IgIkJGRCBvdmVyIExBRyI/IE5vdCBzdXJlDQo+Pj4+IGFzIEkgc2VlIHR3 byBmdW5kYW1lbnRhbCBzZXR1cHM6IChhKSBydW4gQkZEIG9uIGV2ZXJ5DQo+Pj4+IGNvbXBvbmVu dCBsaW5rICBhbmQgKGIpIHJ1biBhIHNpbmdsZSBCRkQgc2Vzc2lvbiBvdmVyIHRoZSBMQUcNCj4+ Pj4gaW50ZXJmYWNlLiBUaGV5IHNvbHZlIGRpZmZlcmVudCBuZXR3b3JrIHNldHVwcyBhcyBmYXIg YXMgSSBjYW4gc2VlLg0KPj4+Pg0KPj4+Pg0KPj4+PiBSZWdhcmRzLCBNYXJjDQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+IE9uIDIwMTEtMDctMjksIGF0IDQ6MTggQU0sIEJoYXRpYSwgTWFuYXYgKE1h bmF2KSB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIEplZmYsDQo+Pj4+Pg0KPj4+Pj4gTGV0IG1lIHVu ZGVyc3RhbmQgdGhpcy4gSWYgeW91IGhhdmUgYW4gSVAgaW50ZXJmYWNlIG92ZXIgYQ0KPj4+PiBM QUcgd2l0aCA1IGNvbXBvbmVudCBsaW5rcywgdGhlbiB5b3UgaW50ZXJuYWxseSBlc3RhYmxpc2gg NQ0KPj4+PiBCRkQgc2Vzc2lvbnMgd2l0aCAzMG1zIHRpbWVvdXRzPw0KPj4+Pj4NCj4+Pj4+IFlv dSBkb24ndCBuZWVkIHRvIGRvIHRoaXMuIFlvdSBjb3VsZCB1c2UgTEFDUCBmb3IgbGFnIGFuZA0K Pj4+PiBCRkQgZm9yIElQIGNvbm5lY3Rpdml0eSAtIHdoaWNoIG1lYW5zIEJGRCBzaG91bGQgcmVt YWluIHVwIGFzDQo+Pj4+IGxvbmcgYXMgdGhlcmUgaXMgcmVhY2hhYmlsaXR5IG92ZXIgdGhlIGxh Zy4gSU1PIGl0IGhhcyBubw0KPj4+PiBidXNpbmVzcyB0byBib3RoZXIgd2l0aCBlYWNoIGluZGl2 aWR1YWwgY29tcG9uZW50IGxpbmtzLg0KPj4+Pj4NCj4+Pj4+IENoZWVycywgTWFuYXYNCj4+Pj4+ DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogSmVmZiBUYW50 c3VyYSBbbWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tXQ0KPj4+Pj4gU2VudDogRnJp ZGF5LCBKdWx5IDI5LCAyMDExIDc6MTUgQU0NCj4+Pj4+IFRvOiBCaGF0aWEsIE1hbmF2IChNYW5h dikNCj4+Pj4+IENjOiBNYWNoIENoZW47IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6 IFJlOiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0DQo+Pj4+Pg0K Pj4+Pj4gSGksDQo+Pj4+Pg0KPj4+Pj4gV2UgaGF2ZSBiZWVuIHN1cHBvcnRpbmcgdGhpcyBtb2Rl IG9mIEJGRCBvdmVyIExBRw0KPj4+PiBvcGVyYXRpb25zIGZvciBsYXN0IDUgeWVhcnMgYW5kIG91 ciBjdXN0b21lcnMgbG92ZSBpdC4NCj4+Pj4+DQo+Pj4+PiBNYW5hdiAtIGltYWdpbmUgeW91IGhh dmUgbG9zdCAzIG91dCBvZiA4IGxpbmtzIGJ1dCBkaWRuJ3QNCj4+Pj4gaGl0IG1pbi1saW5rcywg ZG8geW91IHJlYWxseSB3YW50IHRvIGJyaW5nIHRoZSBMQUcgZG93bj8NCj4+Pj4+DQo+Pj4+PiBN YWNoIC0gYmUgYXdhcmUgb2YgcGF0ZW50cyA6KQ0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+ PiBKZWZmDQo+Pj4+Pg0KPj4+Pj4gT24gSnVsIDI4LCAyMDExLCBhdCAyMToyNSwgIkJoYXRpYSwg TWFuYXYgKE1hbmF2KSINCj4+Pj4gPG1hbmF2LmJoYXRpYUBhbGNhdGVsLWx1Y2VudC5jb20+IHdy b3RlOg0KPj4+Pj4NCj4+Pj4+PiBIaSBNYWNoLA0KPj4+Pj4+DQo+Pj4+Pj4gSSBhbSBub3Qgc3Vy ZSBJIHVuZGVyc3RhbmQgd2h5IHlvdSB3b3VsZCB3YW50IEJGRCB0bw0KPj4+PiBlbnN1cmUgbGl2 ZWxpbmVzcyBvZiBlYWNoIGNvbXBvbmVudCBsaW5rIGluIGEgTEFHLiBUaGUgZHJhZnQNCj4+Pj4g c2VlbXMgdG8gc3VnZ2VzdCBlc3RhYmxpc2hpbmcgc2VwYXJhdGUgQkZEIHNlc3Npb24gZm9yIGVh Y2gNCj4+Pj4gcGFpciBvZiBjb21wb25lbnQgaW50ZXJmYWNlcyB0byBkZXRlY3QgdGhlIGZhaWx1 cmVzLiBXaHkNCj4+Pj4gc2hvdWxkIEJGRCBiZSBjb25jZXJuZWQgYWJvdXQgZWFjaCBjb21wb25l bnQgbGluaz8gSSB3b3VsZA0KPj4+PiByYXRoZXIgdGhhdCBCRkQgc3ByYXlzIHBhY2tldHMgb3Zl ciBlYWNoIGNvbXBvbmVudCBsaW5rIGluIGENCj4+Pj4gcm91bmQgcm9iaW4gZmFzaGlvbiBhbmQg YnJpbmdzIGRvd24gdGhlIElQIGludGVyZmFjZSBvdmVyIGENCj4+Pj4gbGFnIG9ubHkgaWYgaXQg bWlzc2VzIDMgY29uc2VjdXRpdmUgcGFja2V0cy4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4+ Pj4+Pg0KPj4+Pj4+IENoZWVycywgTWFuYXYNCj4+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnDQo+Pj4+ IFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+Pj4+IEJlaGFsZiBPZiBN YWNoIENoZW4NCj4+Pj4+PiBTZW50OiBGcmlkYXksIEp1bHkgMjksIDIwMTEgNDowNSBBTQ0KPj4+ Pj4+IFRvOiBydGctYmZkQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogU29saWNpdCBjb21tZW50 cyBvbiBCRkQgZm9yIEludGVyZmFjZSBkcmFmdA0KPj4+Pj4+DQo+Pj4+Pj4gSGksDQo+Pj4+Pj4N Cj4+Pj4+PiBXZSB1cGxvYWRlZCBhIG5ldw0KPj4+PiBkcmFmdChodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1jaGVuLWJmZC1pbnRlcmZhY2UtMDApDQo+Pj4+IHRoYXQgaXMgYWJvdXQg QkZEIHJ1bm5pbmcgb3ZlciBpbnRlcmZhY2UoZS5nLiwgTEFHL0J1bmRsZQ0KPj4+PiBpbnRlcmZh Y2UpLiBZb3UgYXJlIHZlcnkgd2VsY29tZSB0byByZWFkIHRoZSBkcmFmdCBhbmQgZ2l2ZQ0KPj4+ PiB5b3VyIGNvbW1lbnRzLg0KPj4+Pj4+DQo+Pj4+Pj4gTWFueSB0aGFua3MsDQo+Pj4+Pj4gTWFj aA0KPj4+Pj4NCj4+Pj4NCj4+Pj4gLS0NCj4+Pj4gTWFyYyBCaW5kZXJiZXJnZXIgICAgICAgICAg IDxtYXJjQHNuaWZmLmRlPg0KPj4+Pg0KPj4+Pg0KPj4NCj4+DQo+Pg0KPg0KPg0KPg0KPg0KPg== From manav.bhatia@alcatel-lucent.com Sun Jul 31 23:37:39 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3B21F8557 for ; Sun, 31 Jul 2011 23:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo304IbweFJP for ; Sun, 31 Jul 2011 23:37:38 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2B821F8551 for ; Sun, 31 Jul 2011 23:37:37 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p716belk027011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Aug 2011 01:37:42 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p716bdp6010728 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 1 Aug 2011 12:07:39 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 1 Aug 2011 12:07:39 +0530 Message-ID: <4E36495A.6060108@alcatel-lucent.com> Date: Mon, 1 Aug 2011 12:06:10 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 ThunderBrowse/3.8 MIME-Version: 1.0 To: Subject: Re: =?UTF-8?B?562U5aSNOiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW4=?= =?UTF-8?B?dGVyZmFjZSBkcmFmdA==?= References: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 06:37:39 -0000 Hi Mach, > First, Could you please explain your protocol layering model. Do we now need 2 IP layers, one before LAG termination and one after LAG termination, where the one before LAG termination only understands the well known Multicast IPDA. > > Or implementing this draft assumes bypassing LAG termination when IP-DA is the known multicast proposed in the draft. In other words now LAG termination is conditional on IP address. > > [Mach] From the view of implementation, there is no difference between runing single BFD over a LAG and runing per-link BFD. The key point is how to identify a BFD packet, current as defined in RFC 5880, it uses the UDP port, now for per-link BFD, it uses both multicast IP DA and UDP port. You can do it before or after the LAG termination, it's implementation specific. [Manav] I disagree. Practically, most routers are constrained by the number of BFD packets the system can send and receive per second. If we start sending BFD packets over each component link of the lag, then the number of IP interfaces that can support BFD goes down. Cheers, Manav From mach.chen@huawei.com Sun Jul 31 23:48:38 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945D821F85CA for ; Sun, 31 Jul 2011 23:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-3.318, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gewTy8-jM+xZ for ; Sun, 31 Jul 2011 23:48:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EA23621F8564 for ; Sun, 31 Jul 2011 23:48:37 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800N9SLI106@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 14:46:49 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800JIXLH1B9@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 14:46:49 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACU34746; Mon, 01 Aug 2011 14:46:49 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 01 Aug 2011 14:46:47 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Mon, 01 Aug 2011 14:46:49 +0800 Date: Mon, 01 Aug 2011 06:46:48 +0000 From: Mach Chen Subject: =?gb2312?B?tPC4tDogtPC4tDogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVy?= =?gb2312?Q?face_draft?= In-reply-to: <4E36495A.6060108@alcatel-lucent.com> X-Originating-IP: [172.24.2.41] To: Manav Bhatia , "rtg-bfd@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?tPC4tDogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBk?= =?gb2312?Q?raft?= Thread-index: AQHMTXaSGUO8YfsvQESe7fRUbEFVi5UCgIrw//+AwoCAAAlGgIABSygAgAAZOoCAAR2YAIABcuqAgACPZACAABzigIAAA0OAgAAWUICAACUCAIAAnKsS//+ClACAAIcUVA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.com> <4E36495A.6060108@alcatel-lucent.com> X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 06:48:38 -0000 SGkgTWFuYXYsDQoNCj5QcmFjdGljYWxseSwgbW9zdCByb3V0ZXJzIGFyZSBjb25zdHJhaW5lZCBi eSB0aGUgbnVtYmVyIG9mIEJGRCBwYWNrZXRzIHRoZSBzeXN0ZW0gY2FuIHNlbmQgYW5kIHJlY2Vp dmUgcGVyIHNlY29uZC4gSWYgd2Ugc3RhcnQgc2VuZGluZyBCRkQgcGFja2V0cyBvdmVyIGVhY2gg Y29tcG9uZW50IGxpbmsgb2YgdGhlIGxhZywgdGhlbiB0aGUNCm51bWJlciBvZiBJUCBpbnRlcmZh Y2VzIHRoYXQgY2FuIHN1cHBvcnQgQkZEIGdvZXMgZG93bi4NCg0KSW4gdGhlIGNhc2Ugb2YgY2Vy dGFpbiByZXNvdXJjZXMsIHRoaXMgc2hvdWxkIGJlIHNvLiBZb3UgaGF2ZSB0byBwYXkgdGhpcyBp ZiB5b3Ugd2FudCB0byBkbyBwZXItbGluayBkZXRlY3Rpb24gd2hhdGV2ZXIgdGVjaG5pcXVlcyBh cmUgdXNlZC4gDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCreivP7IyzogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIFtydGct YmZkLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTWFuYXYgQmhhdGlhIFttYW5hdi5iaGF0aWFAYWxj YXRlbC1sdWNlbnQuY29tXQ0Kt6LLzcqxvOQ6IDIwMTHE6jjUwjHI1SAxNDozNg0Ktb06IHJ0Zy1i ZmRAaWV0Zi5vcmcNCtb3zOI6IFJlOiC08Li0OiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3Ig SW50ZXJmYWNlIGRyYWZ0DQoNCkhpIE1hY2gsDQoNCj4gRmlyc3QsIENvdWxkIHlvdSBwbGVhc2Ug ZXhwbGFpbiB5b3VyIHByb3RvY29sIGxheWVyaW5nIG1vZGVsLiBEbyB3ZSBub3cgbmVlZCAyIElQ IGxheWVycywgb25lIGJlZm9yZSBMQUcgdGVybWluYXRpb24gYW5kIG9uZSBhZnRlciBMQUcgdGVy bWluYXRpb24sIHdoZXJlIHRoZSBvbmUgYmVmb3JlIExBRyB0ZXJtaW5hdGlvbiBvbmx5IHVuZGVy c3RhbmRzIHRoZSB3ZWxsIGtub3duIE11bHRpY2FzdCBJUERBLg0KPg0KPiBPciBpbXBsZW1lbnRp bmcgdGhpcyBkcmFmdCBhc3N1bWVzICBieXBhc3NpbmcgTEFHIHRlcm1pbmF0aW9uIHdoZW4gSVAt REEgaXMgdGhlIGtub3duIG11bHRpY2FzdCBwcm9wb3NlZCBpbiB0aGUgZHJhZnQuIEluIG90aGVy IHdvcmRzIG5vdyBMQUcgdGVybWluYXRpb24gaXMgY29uZGl0aW9uYWwgb24gSVAgYWRkcmVzcy4N Cj4NCj4gW01hY2hdIEZyb20gdGhlIHZpZXcgb2YgaW1wbGVtZW50YXRpb24sIHRoZXJlIGlzIG5v IGRpZmZlcmVuY2UgYmV0d2VlbiBydW5pbmcgc2luZ2xlIEJGRCBvdmVyIGEgTEFHIGFuZCBydW5p bmcgcGVyLWxpbmsgQkZELiBUaGUga2V5IHBvaW50IGlzIGhvdyB0byBpZGVudGlmeSBhIEJGRCBw YWNrZXQsIGN1cnJlbnQgYXMgZGVmaW5lZCBpbiBSRkMgNTg4MCwgaXQgdXNlcyB0aGUgVURQIHBv cnQsIG5vdyBmb3IgcGVyLWxpbmsgQkZELCBpdCB1c2VzIGJvdGggbXVsdGljYXN0IElQIERBIGFu ZCBVRFAgcG9ydC4gWW91IGNhbiBkbyBpdCBiZWZvcmUgb3IgYWZ0ZXIgdGhlIExBRyB0ZXJtaW5h dGlvbiwgaXQncyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCg0KW01hbmF2XSBJIGRpc2FncmVl LiBQcmFjdGljYWxseSwgbW9zdCByb3V0ZXJzIGFyZSBjb25zdHJhaW5lZCBieSB0aGUNCm51bWJl ciBvZiBCRkQgcGFja2V0cyB0aGUgc3lzdGVtIGNhbiBzZW5kIGFuZCByZWNlaXZlIHBlciBzZWNv bmQuIElmIHdlDQpzdGFydCBzZW5kaW5nIEJGRCBwYWNrZXRzIG92ZXIgZWFjaCBjb21wb25lbnQg bGluayBvZiB0aGUgbGFnLCB0aGVuIHRoZQ0KbnVtYmVyIG9mIElQIGludGVyZmFjZXMgdGhhdCBj YW4gc3VwcG9ydCBCRkQgZ29lcyBkb3duLg0KDQpDaGVlcnMsIE1hbmF2