From lokeshnb1@gmail.com Fri May 3 00:58:43 2013 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 C9CD321F94D0 for ; Fri, 3 May 2013 00:58:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAYgE1x4B3DC for ; Fri, 3 May 2013 00:58:38 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id B124321F94DF for ; Fri, 3 May 2013 00:58:38 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id k14so1393643oag.0 for ; Fri, 03 May 2013 00:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=6ybROVabSQNPZRi9jUhd5RId6DA4S9N35qbd6KX+SAU=; b=Rpt7gKXkB64fNLZgv3xp+Mh9L0MX0tVNpHGPZ3RwvVpaXq0MrH1AQJhnCkhF7UVzKw DlcsJsqzcRncBHT/ugRqfCimU4LSRkLeoS2txIDAm4H9WRWbutt8sbFSN9vcqvkUCMPT d6WyzXU/WhafyLqeg4V49Bj1z9wH//C2CJkNN29k7f6248+18nQxY22A6M/wBSOFXrzy mV64578ZvO/YWi2css5dhffv2Dva5DefWJHXb720m761kwTWCPvCDhrO8rohFvllraRi vePo3ohMv0JUPUeJMUI5oJhfDCyJr4yigdyGds5sGWe4BWz/mk3alDl/Au6E7WU7oC9b pttg== MIME-Version: 1.0 X-Received: by 10.182.45.197 with SMTP id p5mr141476obm.92.1367567918244; Fri, 03 May 2013 00:58:38 -0700 (PDT) Received: by 10.76.154.163 with HTTP; Fri, 3 May 2013 00:58:38 -0700 (PDT) Date: Fri, 3 May 2013 13:28:38 +0530 Message-ID: Subject: few queries regarding BFD From: Lokesh NB To: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=047d7b67637af92f5a04dbcbb7f2 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, 03 May 2013 07:58:43 -0000 --047d7b67637af92f5a04dbcbb7f2 Content-Type: text/plain; charset=ISO-8859-1 Hi All I'm trying to design BFD for a router, I have couple of questions related to capacity planning and want to know what is the general industry deployment trend in those areas. Any answers are greatly appreciated. 1. How to arrive at maximum number of BFD sessions to be supported in a high end router.? 2. what is the currently supported maximum number of BFD sessions in high end routers? is it in the orders of hundreds of thousands? 3. What is the minimum Tx time to be supported for layer 3 UDP encap peers? I know cisco supports minimum 50 msec but can we expect requirement for IP peers to be monitored below that 50 msecs? like 10,20 msec? 4. What is average Tx time usually IP peers settle for in general? is it like 100-300 msec? In other words what is usually configured Tx time for IP peers? 5. What is the expected percentage of BFD traffic of the total bandwidth of the device? I know it depends on how many sessions are active in parallel and Tx/Rx timers but in general is it correct to estimate that BFD traffic generally should not exceed 2 to 5 % of the total bandwidth available for user data? 6. How frequently Auth is used in general deployments? is it only used for multi hop peers usually? Regards -Lokesh --047d7b67637af92f5a04dbcbb7f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All

I'm = trying to design BFD for a router, I have couple of questions related to ca= pacity planning and want to know what is the general industry deployment tr= end in those areas.=A0 Any answers are greatly appreciated.

1. How to arrive at maximum number of BFD sessions to = be supported in a high end router.?

2. what is the currently s= upported maximum number of BFD sessions in high end routers? is it in the o= rders of hundreds of thousands?

3. What is the minimum Tx time to be supported for layer 3 U= DP encap peers? I know cisco supports minimum 50 msec but can we expect req= uirement for IP peers to be monitored below that 50 msecs? like 10,20 msec?=

4. What is average Tx time usually IP peers settle for in ge= neral? is it like 100-300 msec? In other words what is usually configured T= x time for IP peers?

5. What is the expected percen= tage of BFD traffic of the total bandwidth of the device? I know it depends= on how many sessions are active in parallel and Tx/Rx timers but in genera= l is it correct to estimate that BFD traffic generally should not exceed 2 = to 5 % of the total bandwidth available for user data?

6. How frequently Auth is used in general deployments? is it= only used for multi hop peers usually?

Regards
-Lokesh






--047d7b67637af92f5a04dbcbb7f2-- From binnyjeshan@gmail.com Fri May 3 01:37:46 2013 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 57F0221F9488 for ; Fri, 3 May 2013 01:37:46 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KakTGkdBw-yo for ; Fri, 3 May 2013 01:37:45 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 309A521F9501 for ; Fri, 3 May 2013 01:37:45 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id fh20so1305130lab.20 for ; Fri, 03 May 2013 01:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oukAPQqfsyMePMfFMgHGtnklO4f2sccInv45HJVh4tQ=; b=HEN6BosTNV+yGdd71vXguUo3iYmf5WL6P6Dx4DkvylWX0c3dnmH1+YvKbP8KIjSlsu WRIjoeV6ivFcJ7WDbCLJX7pGDUm30vcb25V5THYS78HFOpmyZY23rRPlvQ2JxdrqQDat spnEY6u30xvD1tMwMARcgHiq2IqwjI3TScdN87X1xL3fOBiUb1jB79u4enajAk+DqUTk NCB4CSzjM9+bZhPnLN/FLNcEw70MFXA155Xc33opmf6x6liDhlg7heMCs2UE6uKx2WFM 56fNfbsum+dit9vdY7mKcSUrxLI7suKNnYQaCIc50P38P3VB7FWo+1katmDHxVZbpiX9 ZLcA== MIME-Version: 1.0 X-Received: by 10.112.74.193 with SMTP id w1mr3833475lbv.125.1367570264070; Fri, 03 May 2013 01:37:44 -0700 (PDT) Received: by 10.114.160.20 with HTTP; Fri, 3 May 2013 01:37:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 May 2013 14:07:43 +0530 Message-ID: Subject: Re: few queries regarding BFD From: Binny Jeshan To: Lokesh NB Content-Type: multipart/alternative; boundary=14dae9d25478cba05004dbcc430d 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, 03 May 2013 08:37:46 -0000 --14dae9d25478cba05004dbcc430d Content-Type: text/plain; charset=ISO-8859-1 Hi Lokesh, My views on this: 1. This depends on how many paths you need to monitor and number of probable combinations with which you need to monitor one path. This depends on your system and deployment requirement majorly. 2. Could run few thousands. 3. if 50 ms is the total switchover requirement, you atleast need to have 5ms Tx timer + Detect multiplier 2 = to confine within 10ms detection time of the total available 50 ms. That again depends on your system performance on swithover. Again it totally depends on operators need. 4. Nowhere you will be able to get this accurate stats. 5. This is your system requirement. You will need to define it. Just make sure that congestion requirements are met. 6. Cannot comment anything solid again. Auth is used if you need to hide your information. You may not get exact answers in this forum :( Thanks, Binny Jeshan. On 3 May 2013 13:28, Lokesh NB wrote: > Hi All > > I'm trying to design BFD for a router, I have couple of questions related > to capacity planning and want to know what is the general industry > deployment trend in those areas. Any answers are greatly appreciated. > > 1. How to arrive at maximum number of BFD sessions to be supported in a > high end router.? > > 2. what is the currently supported maximum number of BFD sessions in high > end routers? is it in the orders of hundreds of thousands? > > 3. What is the minimum Tx time to be supported for layer 3 UDP encap > peers? I know cisco supports minimum 50 msec but can we expect requirement > for IP peers to be monitored below that 50 msecs? like 10,20 msec? > > 4. What is average Tx time usually IP peers settle for in general? is it > like 100-300 msec? In other words what is usually configured Tx time for IP > peers? > > 5. What is the expected percentage of BFD traffic of the total bandwidth > of the device? I know it depends on how many sessions are active in > parallel and Tx/Rx timers but in general is it correct to estimate that BFD > traffic generally should not exceed 2 to 5 % of the total bandwidth > available for user data? > > 6. How frequently Auth is used in general deployments? is it only used for > multi hop peers usually? > > Regards > -Lokesh > > > > > > > --14dae9d25478cba05004dbcc430d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Lokesh,

My views on this:

1. This depends on how many paths you need= to monitor and number of probable combinations with which you need to moni= tor one path. This depends on your system and deployment requirement majorl= y.

2. Could run few thousands.

3. if 50 ms is the total switchover requirement, you = atleast need to have 5ms Tx timer + Detect multiplier 2 =3D to confine with= in 10ms detection time of the total available 50 ms. That again depends on = your system performance on swithover. Again it totally depends on operators= need.=A0

4. Nowhere you will be able to get this acc= urate stats.=A0

5. This is your system= requirement. You will need to define it. Just make sure that congestion re= quirements are met.

6. Cannot comment anything solid again. Aut= h is used if you need to hide your information. You may not get exact answe= rs in this forum :(

Thanks,
Binny Jeshan.


On 3 May 2013 13:28, Lokesh NB <lokeshnb1@gmail.com><= /span> wrote:
Hi= All

I'm trying to design BFD for a router, I have co= uple of questions related to capacity planning and want to know what is the= general industry deployment trend in those areas.=A0 Any answers are great= ly appreciated.

1. How to arrive at maximum number of BFD sessions to = be supported in a high end router.?

2. what is the currently s= upported maximum number of BFD sessions in high end routers? is it in the o= rders of hundreds of thousands?

3. What is the minimum Tx time to be supported for layer 3 U= DP encap peers? I know cisco supports minimum 50 msec but can we expect req= uirement for IP peers to be monitored below that 50 msecs? like 10,20 msec?=

4. What is average Tx time usually IP peers settle for in ge= neral? is it like 100-300 msec? In other words what is usually configured T= x time for IP peers?

5. What is the expected percen= tage of BFD traffic of the total bandwidth of the device? I know it depends= on how many sessions are active in parallel and Tx/Rx timers but in genera= l is it correct to estimate that BFD traffic generally should not exceed 2 = to 5 % of the total bandwidth available for user data?

6. How frequently Auth is used in general deployments? is it= only used for multi hop peers usually?

Regards
-Lokesh







--14dae9d25478cba05004dbcc430d-- From lokeshnb1@gmail.com Fri May 3 02:35:28 2013 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 3840621F9416 for ; Fri, 3 May 2013 02:35:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMN8OHvkMNYe for ; Fri, 3 May 2013 02:35:23 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 04C4821F93E9 for ; Fri, 3 May 2013 02:35:22 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id n9so1412745oag.40 for ; Fri, 03 May 2013 02:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xLnfdGC2Ts2tZpRpyBi0BPoHRp6eesSxHwU/t1Ez5IY=; b=gwtAF2mvnwugP23UeeigytScpeh8MGj4B4wzx4BhdPFImuLXkMnoyFbeAOFfOMdJ5P EOLTX6WQPhdV1TAxTbsrXqQFJxYLHcwlcKMF2/RaorCn6Tl30GhSwObK9e2nvJfWu1yR VeXhMnD8SCQS8fkMsF0m1U7WuDx3l/AXK894W9NnpxQtKkqsimHXtV1HULvgrZZHO+XM 9GEa5O3/UtVTUnA+blFy3oDIIrtpAoaPFsDyEJ29WwfLSrtvx72tSj/Urv+7RkCCSwUD NbNqTpcqET8zAElq+ct5v1vjbA0Caw33hhFnLoJccpSR/oeQ+PsKpG0CLF3TZLjGoRXn vjAw== MIME-Version: 1.0 X-Received: by 10.60.79.131 with SMTP id j3mr2798201oex.71.1367573722608; Fri, 03 May 2013 02:35:22 -0700 (PDT) Received: by 10.76.154.163 with HTTP; Fri, 3 May 2013 02:35:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 May 2013 15:05:22 +0530 Message-ID: Subject: Re: few queries regarding BFD From: Lokesh NB To: Binny Jeshan Content-Type: multipart/alternative; boundary=047d7b678126f0bafc04dbcd118c 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, 03 May 2013 09:35:28 -0000 --047d7b678126f0bafc04dbcd118c Content-Type: text/plain; charset=ISO-8859-1 Thanks binny for answers, yes, I know these are system requirements. I want to plan my system requirements in line with general industry acceptable numbers. As I'm new to this area I have very little idea on what are the new trends in the BFD capacity setting in high end routers. Do you know any link or discussion on these things on internet or elsewhere? Regards -Lokesh On Fri, May 3, 2013 at 2:07 PM, Binny Jeshan wrote: > Hi Lokesh, > > My views on this: > > 1. This depends on how many paths you need to monitor and number of > probable combinations with which you need to monitor one path. This depends > on your system and deployment requirement majorly. > > 2. Could run few thousands. > > 3. if 50 ms is the total switchover requirement, you atleast need to have > 5ms Tx timer + Detect multiplier 2 = to confine within 10ms detection time > of the total available 50 ms. That again depends on your system performance > on swithover. Again it totally depends on operators need. > > 4. Nowhere you will be able to get this accurate stats. > > 5. This is your system requirement. You will need to define it. Just make > sure that congestion requirements are met. > > 6. Cannot comment anything solid again. Auth is used if you need to hide > your information. You may not get exact answers in this forum :( > > Thanks, > Binny Jeshan. > > > On 3 May 2013 13:28, Lokesh NB wrote: > >> Hi All >> >> I'm trying to design BFD for a router, I have couple of questions related >> to capacity planning and want to know what is the general industry >> deployment trend in those areas. Any answers are greatly appreciated. >> >> 1. How to arrive at maximum number of BFD sessions to be supported in a >> high end router.? >> >> 2. what is the currently supported maximum number of BFD sessions in high >> end routers? is it in the orders of hundreds of thousands? >> >> 3. What is the minimum Tx time to be supported for layer 3 UDP encap >> peers? I know cisco supports minimum 50 msec but can we expect requirement >> for IP peers to be monitored below that 50 msecs? like 10,20 msec? >> >> 4. What is average Tx time usually IP peers settle for in general? is it >> like 100-300 msec? In other words what is usually configured Tx time for IP >> peers? >> >> 5. What is the expected percentage of BFD traffic of the total bandwidth >> of the device? I know it depends on how many sessions are active in >> parallel and Tx/Rx timers but in general is it correct to estimate that BFD >> traffic generally should not exceed 2 to 5 % of the total bandwidth >> available for user data? >> >> 6. How frequently Auth is used in general deployments? is it only used >> for multi hop peers usually? >> >> Regards >> -Lokesh >> >> >> >> >> >> >> > --047d7b678126f0bafc04dbcd118c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks binny for answers,
yes, I k= now these are system requirements. I want to plan my system requirements in= line with general industry acceptable numbers. As I'm new to this area= I have very little idea on what are the new trends in the BFD capacity set= ting in high end routers. Do you know any link or discussion on these thing= s on internet or elsewhere?
Regards
-Lokesh


=
On Fri, May 3, 2013 at 2:07 PM, Binny Jeshan <binnyjeshan@gmail.com> wrote:
Hi Lokesh,

My views on this:

1. This depends on how many p= aths you need to monitor and number of probable combinations with which you= need to monitor one path. This depends on your system and deployment requi= rement majorly.

2. Could run few thousands.

3.= if 50 ms is the total switchover requirement, you atleast need to have 5ms= Tx timer + Detect multiplier 2 =3D to confine within 10ms detection time o= f the total available 50 ms. That again depends on your system performance = on swithover. Again it totally depends on operators need.=A0

4. Nowhere you will be able to get this accurate stats.= =A0

5. This is your system requirement. You will n= eed to define it. Just make sure that congestion requirements are met.

6. Cannot comment anything solid again. Auth is used if= you need to hide your information. You may not get exact answers in this f= orum :(

Thanks,
Binny Jeshan.


On 3 May 2013 13:28, Lokesh NB <lokeshnb1@gmail.com><= /span> wrote:
Hi= All

I'm trying to design BFD for a router, I have co= uple of questions related to capacity planning and want to know what is the= general industry deployment trend in those areas.=A0 Any answers are great= ly appreciated.

1. How to arrive at maximum number of BFD sessions to = be supported in a high end router.?

2. what is the currently s= upported maximum number of BFD sessions in high end routers? is it in the o= rders of hundreds of thousands?

3. What is the minimum Tx time to be supported for layer 3 U= DP encap peers? I know cisco supports minimum 50 msec but can we expect req= uirement for IP peers to be monitored below that 50 msecs? like 10,20 msec?=

4. What is average Tx time usually IP peers settle for in ge= neral? is it like 100-300 msec? In other words what is usually configured T= x time for IP peers?

5. What is the expected percen= tage of BFD traffic of the total bandwidth of the device? I know it depends= on how many sessions are active in parallel and Tx/Rx timers but in genera= l is it correct to estimate that BFD traffic generally should not exceed 2 = to 5 % of the total bandwidth available for user data?

6. How frequently Auth is used in general deployments? is it= only used for multi hop peers usually?

Regards
-Lokesh








--047d7b678126f0bafc04dbcd118c-- From marc@sniff.de Fri May 3 03:00:44 2013 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 9BC1D21F86E7 for ; Fri, 3 May 2013 03:00:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd6xkgESf6za for ; Fri, 3 May 2013 03:00:44 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E365821F8763 for ; Fri, 3 May 2013 03:00:40 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 74F992AA0F; Fri, 3 May 2013 10:00:34 +0000 (GMT) Subject: Re: few queries regarding BFD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Fri, 3 May 2013 12:00:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lokesh NB 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, 03 May 2013 10:00:44 -0000 Hello Lokesh, some questions are quite generic but nevertheless ... > 1. How to arrive at maximum number of BFD sessions to be supported in = a high end router.? distributed architecture and/or using ASIC/FPGA/NP to offload the packet = Tx/Rx > 2. what is the currently supported maximum number of BFD sessions in = high end routers? is it in the orders of hundreds of thousands?=20 Thousands. Details may depend on the timer values when the = implementation is software based, still system-wide I stick to = "thousands". > 3. What is the minimum Tx time to be supported for layer 3 UDP encap = peers? I know cisco supports minimum 50 msec but can we expect = requirement for IP peers to be monitored below that 50 msecs? like 10,20 = msec? Actually this particular vendor you mention supports 15msec for high-end = equipment today. With a multiplier of 2 that makes a detection time of = 30msec maximum, so depending on the fiber length in a network that could = make the 50-60msec time for detection & restoration. Obviously: the faster the timer the better :-) , for MPLS-TP OAM the = usual number you hear is 3.3msec (so 10msec detection time with a = multiplier of 3). > 4. What is average Tx time usually IP peers settle for in general? is = it like 100-300 msec? In other words what is usually configured Tx time = for IP peers? there is no single number, too many network designs out there in real = life. In the core customers typically go fast, to the endpoints some = customers go slower, just to stay below 1sec detection time so VoIP = controller don't freak out.=20 Regards, Marc > 5. What is the expected percentage of BFD traffic of the total = bandwidth of the device? I know it depends on how many sessions are = active in parallel and Tx/Rx timers but in general is it correct to = estimate that BFD traffic generally should not exceed 2 to 5 % of the = total bandwidth available for user data? >=20 > 6. How frequently Auth is used in general deployments? is it only used = for multi hop peers usually?=20 >=20 > Regards > -Lokesh >=20 >=20 >=20 >=20 >=20 >=20 From binnyjeshan@gmail.com Fri May 3 03:23:17 2013 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 873BC21F8763 for ; Fri, 3 May 2013 03:23:16 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCQIjfTW3vGp for ; Fri, 3 May 2013 03:23:15 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2621F90B1 for ; Fri, 3 May 2013 03:23:14 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fq13so1386457lab.29 for ; Fri, 03 May 2013 03:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Jqu6mDEb1z6qNdq9dB/P4Gdw8Wgkj+kKPuF8+ZxCX/M=; b=Omox93dCzzkVuQpuEl45PPKBdiZ2nDoHMgncqlU/HTwaJ6LmWuuZa4pxl1zMus9Cuf XLZqSeEFPMRnD6CH9uqhcINOYn67CHECbNCkIQx2m8i4JHWSjQPsUVFPvfZ7VElpVgzj Rxb/2lNyVV6y9Ya59IvP1LMVMlbQiDF6g6EPh9TwinJi9z7XGJEOOGjlb009EHjbQ1a5 dQKBYDerIb15b3qkutJujT8JHZofw36jTpkgYnCXKv9dc0hcdsGXGR32e9ydjiI/hWMq x1zUkskfEiIph2+NRElqgujsmvL4koxEQMAcyxdoJ9fP9qbx/MRR+uu+tgjEIajzb6pJ dkcg== MIME-Version: 1.0 X-Received: by 10.112.5.137 with SMTP id s9mr4118629lbs.68.1367576593369; Fri, 03 May 2013 03:23:13 -0700 (PDT) Received: by 10.114.160.20 with HTTP; Fri, 3 May 2013 03:23:13 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 May 2013 15:53:13 +0530 Message-ID: Subject: Re: few queries regarding BFD From: Binny Jeshan To: Marc Binderberger Content-Type: multipart/alternative; boundary=14dae94ed61b0d27f504dbcdbd0c 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, 03 May 2013 10:23:17 -0000 --14dae94ed61b0d27f504dbcdbd0c Content-Type: text/plain; charset=ISO-8859-1 Hello Lokesh, For the Authenication part, i would suggest please go ahead and provide that functionality. Its optional anyways to use it in reality. Regards, Binny On 3 May 2013 15:30, Marc Binderberger wrote: > Hello Lokesh, > > some questions are quite generic but nevertheless ... > > > > 1. How to arrive at maximum number of BFD sessions to be supported in a > high end router.? > > distributed architecture and/or using ASIC/FPGA/NP to offload the packet > Tx/Rx > > > > 2. what is the currently supported maximum number of BFD sessions in > high end routers? is it in the orders of hundreds of thousands? > > Thousands. Details may depend on the timer values when the implementation > is software based, still system-wide I stick to "thousands". > > > > 3. What is the minimum Tx time to be supported for layer 3 UDP encap > peers? I know cisco supports minimum 50 msec but can we expect requirement > for IP peers to be monitored below that 50 msecs? like 10,20 msec? > > Actually this particular vendor you mention supports 15msec for high-end > equipment today. With a multiplier of 2 that makes a detection time of > 30msec maximum, so depending on the fiber length in a network that could > make the 50-60msec time for detection & restoration. > > Obviously: the faster the timer the better :-) , for MPLS-TP OAM the usual > number you hear is 3.3msec (so 10msec detection time with a multiplier of > 3). > > > > 4. What is average Tx time usually IP peers settle for in general? is it > like 100-300 msec? In other words what is usually configured Tx time for IP > peers? > > there is no single number, too many network designs out there in real > life. In the core customers typically go fast, to the endpoints some > customers go slower, just to stay below 1sec detection time so VoIP > controller don't freak out. > > > Regards, Marc > > > > > 5. What is the expected percentage of BFD traffic of the total bandwidth > of the device? I know it depends on how many sessions are active in > parallel and Tx/Rx timers but in general is it correct to estimate that BFD > traffic generally should not exceed 2 to 5 % of the total bandwidth > available for user data? > > > > 6. How frequently Auth is used in general deployments? is it only used > for multi hop peers usually? > > > > Regards > > -Lokesh > > > > > > > > > > > > > > > --14dae94ed61b0d27f504dbcdbd0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Lokesh,

For the Authenicati= on part, i would suggest please go ahead and provide that functionality. It= s optional anyways to use it in reality.

Regards,
Binny

On 3 May 2013 15:30, Marc Binderberger <marc@snif= f.de> wrote:
Hello Lokesh,

some questions are quite generic but nevertheless ...


> 1. How to arrive at maximum number of BFD sessions to be supported in = a high end router.?

distributed architecture and/or using ASIC/FPGA/NP to offload the pac= ket Tx/Rx


> 2. what is the currently supported maximum number of BFD sessions in h= igh end routers? is it in the orders of hundreds of thousands?

Thousands. Details may depend on the timer values when the implementa= tion is software based, still system-wide I stick to "thousands".=


> 3. What is the minimum Tx time to be supported for layer 3 UDP encap p= eers? I know cisco supports minimum 50 msec but can we expect requirement f= or IP peers to be monitored below that 50 msecs? like 10,20 msec?

Actually this particular vendor you mention supports 15msec for high-= end equipment today. With a multiplier of 2 that makes a detection time of = 30msec maximum, so depending on the fiber length in a network that could ma= ke the 50-60msec time for detection & restoration.

Obviously: the faster the timer the better :-) , for MPLS-TP OAM the usual = number you hear is 3.3msec (so 10msec detection time with a multiplier of 3= ).


> 4. What is average Tx time usually IP peers settle for in general? is = it like 100-300 msec? In other words what is usually configured Tx time for= IP peers?

there is no single number, too many network designs out there in real= life. In the core customers typically go fast, to the endpoints some custo= mers go slower, just to stay below 1sec detection time so VoIP controller d= on't freak out.


Regards, Marc



> 5. What is the expected percentage of BFD traffic of the total bandwid= th of the device? I know it depends on how many sessions are active in para= llel and Tx/Rx timers but in general is it correct to estimate that BFD tra= ffic generally should not exceed 2 to 5 % of the total bandwidth available = for user data?
>
> 6. How frequently Auth is used in general deployments? is it only used= for multi hop peers usually?
>
> Regards
> -Lokesh
>
>
>
>
>
>



--14dae94ed61b0d27f504dbcdbd0c-- From kristian@spritelink.net Fri May 3 04:45:10 2013 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 3B0D021F95D7 for ; Fri, 3 May 2013 04:45: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lohr7OIxKjlk for ; Fri, 3 May 2013 04:45:05 -0700 (PDT) Received: from Mail2.SpriteLink.NET (mail2.spritelink.net [194.9.8.122]) by ietfa.amsl.com (Postfix) with ESMTP id 09EFB21F92F7 for ; Fri, 3 May 2013 04:45:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 8089E1CC9A for ; Fri, 3 May 2013 13:45:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([194.9.8.122]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlGpg8aWtvRW for ; Fri, 3 May 2013 13:44:45 +0200 (CEST) Received: from [172.16.93.215] (workstation.tele2.se [192.71.219.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id C232D1CC41 for ; Fri, 3 May 2013 13:44:45 +0200 (CEST) Message-ID: <5183A32D.6020602@spritelink.net> Date: Fri, 03 May 2013 13:44:45 +0200 From: Kristian Larsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: rtg-bfd@ietf.org Subject: Re: few queries regarding BFD References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 03 May 2013 11:45:10 -0000 On 05/03/2013 09:58 AM, Lokesh NB wrote: > Hi All > > I'm trying to design BFD for a router, I have couple of questions > related to capacity planning and want to know what is the general > industry deployment trend in those areas. Any answers are greatly > appreciated. > > 1. How to arrive at maximum number of BFD sessions to be supported in > a high end router.? Depends on number of ports. For a core router you typically need one very high frequency BFD per port while for a edge router with thousands of customers you will need as many BFD sessions as you have customer ports but perhaps at a somewhat lower rate. > > 2. what is the currently supported maximum number of BFD sessions in > high end routers? is it in the orders of hundreds of thousands? Most high end routers distribute the BFD processing to the linecards. The ASR9k for example support ~6.7kPPS per linecard CPU - see http://www9.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r3.9/interfaces/configuration/guide/hc39bifw.html > > 3. What is the minimum Tx time to be supported for layer 3 UDP encap > peers? I know cisco supports minimum 50 msec but can we expect > requirement for IP peers to be monitored below that 50 msecs? like > 10,20 msec? Cisco supports 15ms on IOS XR and I think it is reasonable to support something like 10ms (keepalive) to achieve failure detection in 30ms and able to converge in 50ms. > > 4. What is average Tx time usually IP peers settle for in general? is > it like 100-300 msec? In other words what is usually configured Tx > time for IP peers? I know of one rather large European IP network that does 3x15ms on core links and prefer 3x50ms on eBGP sessions. > > 5. What is the expected percentage of BFD traffic of the total > bandwidth of the device? I know it depends on how many sessions are > active in parallel and Tx/Rx timers but in general is it correct to > estimate that BFD traffic generally should not exceed 2 to 5 % of the > total bandwidth available for user data? Insignificant on 10G links. > 6. How frequently Auth is used in general deployments? is it only used > for multi hop peers usually? No idea. Kind regards, Kristian. > > Regards > -Lokesh > > > > > > From lokeshnb1@gmail.com Mon May 6 02:28:35 2013 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 EB72F21F877B for ; Mon, 6 May 2013 02:28:34 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLQZj6IKYAvQ for ; Mon, 6 May 2013 02:28:34 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0B21F85D6 for ; Mon, 6 May 2013 02:28:33 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id v19so2919134obq.30 for ; Mon, 06 May 2013 02:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9Wyj4OJ6Cx6MTUSzI1ziTR9pGCpHEZ1GQkvDwC+Ng7g=; b=lfLWeRchFxvZXhV8RVCjllbtZ7fM+QEwRUZI25DwSqIbfuuvQ0X63s4biIa+YskOsz miM91PrZIIr/OCuC+OJ6ITEa4F0yzcEYfVNI8gJLCjh2lEl36pNLQfkZdWBxR/JqOujH e/wgpuH1fWHeEr5uYdRY2Om+NVZz2DzD+0DjQEzcIdqQUZKJY9bT2Pfj6Fop6TFqlSIP rD6Ww+AEn7dDD9Ep7c0SzeEKQlggXXX/RbmmefVDgGwrIfjHjRxIDedePAW0wZANz7Jt qOxHz53A8XlKA0FT3S4eP3kbbpfVSNJypxPsVelf/YoUfJuNDPA2c4CAtKnO43Tx3+6t s0wg== MIME-Version: 1.0 X-Received: by 10.182.46.228 with SMTP id y4mr5294589obm.28.1367832513549; Mon, 06 May 2013 02:28:33 -0700 (PDT) Received: by 10.76.154.163 with HTTP; Mon, 6 May 2013 02:28:33 -0700 (PDT) In-Reply-To: <5183A32D.6020602@spritelink.net> References: <5183A32D.6020602@spritelink.net> Date: Mon, 6 May 2013 14:58:33 +0530 Message-ID: Subject: Re: few queries regarding BFD From: Lokesh NB To: Kristian Larsson Content-Type: multipart/alternative; boundary=089e0111dd5a151e4304dc09533a 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, 06 May 2013 09:28:35 -0000 --089e0111dd5a151e4304dc09533a Content-Type: text/plain; charset=ISO-8859-1 Kristian, Marc, Binny Thank you all ! Greatly appreciate your help ! Regards -Lokesh. On Fri, May 3, 2013 at 5:14 PM, Kristian Larsson wrote: > On 05/03/2013 09:58 AM, Lokesh NB wrote: > > Hi All > > > > I'm trying to design BFD for a router, I have couple of questions > > related to capacity planning and want to know what is the general > > industry deployment trend in those areas. Any answers are greatly > > appreciated. > > > > 1. How to arrive at maximum number of BFD sessions to be supported in > > a high end router.? > Depends on number of ports. For a core router you typically need one > very high frequency BFD per port while for a edge router with thousands > of customers you will need as many BFD sessions as you have customer > ports but perhaps at a somewhat lower rate. > > > > > 2. what is the currently supported maximum number of BFD sessions in > > high end routers? is it in the orders of hundreds of thousands? > Most high end routers distribute the BFD processing to the linecards. > The ASR9k for example support ~6.7kPPS per linecard CPU - see > > http://www9.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r3.9/interfaces/configuration/guide/hc39bifw.html > > > > > 3. What is the minimum Tx time to be supported for layer 3 UDP encap > > peers? I know cisco supports minimum 50 msec but can we expect > > requirement for IP peers to be monitored below that 50 msecs? like > > 10,20 msec? > > Cisco supports 15ms on IOS XR and I think it is reasonable to support > something like 10ms (keepalive) to achieve failure detection in 30ms and > able to converge in 50ms. > > > > > 4. What is average Tx time usually IP peers settle for in general? is > > it like 100-300 msec? In other words what is usually configured Tx > > time for IP peers? > I know of one rather large European IP network that does 3x15ms on core > links and prefer 3x50ms on eBGP sessions. > > > > > 5. What is the expected percentage of BFD traffic of the total > > bandwidth of the device? I know it depends on how many sessions are > > active in parallel and Tx/Rx timers but in general is it correct to > > estimate that BFD traffic generally should not exceed 2 to 5 % of the > > total bandwidth available for user data? > > Insignificant on 10G links. > > > > 6. How frequently Auth is used in general deployments? is it only used > > for multi hop peers usually? > No idea. > > Kind regards, > Kristian. > > > > > Regards > > -Lokesh > > > > > > > > > > > > > > --089e0111dd5a151e4304dc09533a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kristian, Marc, Binny=A0
Thank you all= =A0 !
Greatly appreciate your help !

Regards
-Lokesh.


On Fri, May 3, 2013 at 5:14 PM, Kristian Larsson &l= t;kristian@spr= itelink.net> wrote:
On 05/03/2013 09:58 AM, Lokesh NB wrote:
> Hi All
>
> I'm trying to design BFD for a router, I have couple of questions<= br> > related to capacity planning and want to know what is the general
> industry deployment trend in those areas. =A0Any answers are greatly > appreciated.
>
> 1. How to arrive at maximum number of BFD sessions to be supported in<= br> > a high end router.?
Depends on number of ports. For a core router you typically need one
very high frequency BFD per port while for a edge router with thousands
of customers you will need as many BFD sessions as you have customer
ports but perhaps at a somewhat lower rate.

>
> 2. what is the currently supported maximum number of BFD sessions in > high end routers? is it in the orders of hundreds of thousands?
Most high end routers distribute the BFD processing to the linecards.
The ASR9k for example support ~6.7kPPS per linecard CPU - see
http:/= /www9.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r3.9/interfaces/c= onfiguration/guide/hc39bifw.html

>
> 3. What is the minimum Tx time to be supported for layer 3 UDP encap > peers? I know cisco supports minimum 50 msec but can we expect
> requirement for IP peers to be monitored below that 50 msecs? like
> 10,20 msec?

Cisco supports 15ms on IOS XR and I think it is reasonable to support
something like 10ms (keepalive) to achieve failure detection in 30ms and able to converge in 50ms.

>
> 4. What is average Tx time usually IP peers settle for in general? is<= br> > it like 100-300 msec? In other words what is usually configured Tx
> time for IP peers?
I know of one rather large European IP network that does 3x15ms on core
links and prefer 3x50ms on eBGP sessions.

>
> 5. What is the expected percentage of BFD traffic of the total
> bandwidth of the device? I know it depends on how many sessions are > active in parallel and Tx/Rx timers but in general is it correct to > estimate that BFD traffic generally should not exceed 2 to 5 % of the<= br> > total bandwidth available for user data?

Insignificant on 10G links.


> 6. How frequently Auth is used in general deployments? is it only used=
> for multi hop peers usually?
No idea.

Kind regards,
=A0 =A0 Kristian.

>
> Regards
> -Lokesh
>
>
>
>
>
>


--089e0111dd5a151e4304dc09533a-- From nobo@cisco.com Tue May 7 09:15:54 2013 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 CDB2621F854E for ; Tue, 7 May 2013 09:15:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgKx4MWy+LaG for ; Tue, 7 May 2013 09:15:49 -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 AADBD21F8539 for ; Tue, 7 May 2013 09:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2492; q=dns/txt; s=iport; t=1367943349; x=1369152949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YGMB8eQUKkFuOW9XPT4RXwGW6cfafKGzOyJAydwN64M=; b=cRHMxLCwxv+yaZpw/MWmnekJDYD+RcHpTvKXahZeRgT6k5ShtR5vXG3r tF5n0dB8APD+Ob0Lik86YBcgVsYm+x6SnGYc3vahFbBSnP92bBqeZlG/P NtAuET82aUKPzqzYK2IHoQlAnO9dHZtZIZOrVBqzbxK6wD3i2rGp0OoKH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAGUniVGtJXG9/2dsb2JhbABQgmYhN0SCeLtNDXsWbQeCHwEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEICAIEDgUIAYgDAQYFsEWCQY5FgSaNXBYbBwaCPDJhA5hVkBGDDoIn X-IronPort-AV: E=Sophos;i="4.87,629,1363132800"; d="scan'208";a="207459604" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 07 May 2013 16:15:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r47GFnPr007384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 May 2013 16:15:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 7 May 2013 11:15:48 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-mbind-bfd-redundancy-01.txt Thread-Topic: New Version Notification for draft-mbind-bfd-redundancy-01.txt Thread-Index: AQHOSz0jrSNBtybugkWJoRqk1+vF7Zj54/DQ Date: Tue, 7 May 2013 16:15:48 +0000 Message-ID: References: <20130507160834.23471.66090.idtracker@ietfa.amsl.com> In-Reply-To: <20130507160834.23471.66090.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Marc Binderberger \(mbinderb\)" 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: Tue, 07 May 2013 16:15:55 -0000 SGVsbG8gQkZEIFdHIE1lbWJlcnMsDQoNCk1hcmMgYW5kIG15c2VsZiBoYXZlIGp1c3Qgcm9sbGVk IG91dCByZXYgLTAxIG9mIEJGRCByZWR1bmRhbmN5IGRyYWZ0Lg0KDQpTb21lIG1pbm9yIGNoYW5n ZXMgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQsIGJ1dCBjb3JlIGNoYW5nZXMgYXJlOg0KDQooMSkg U2VjdGlvbiAyIGhhcyBiZWVuIHJlLXdyaXR0ZW4gdG8gYmV0dGVyIGRlc2NyaWJlIHVzZSBjYXNl IHNjZW5hcmlvcy4NCigyKSBTZWN0aW9uIDcgaGFzIGJlZW4gYWRkZWQgdG8gZGVzY3JpYmUgaG93 IHRoZSBtZWNoYW5pc20gd29ya3MgZm9yIExTUCBwaW5nIGJvb3RzdHJhcHBlZCBzZXNzaW9ucy4N Cg0KV2UgYmVsaWV2ZSB0aGF0IHRoaXMgcmV2aXNpb24gbWFrZXMgYmV0dGVyIHJlYWRpbmcgbWF0 ZXJpYWwgb3ZlciBjb2ZmZWUsIGFuZCB3ZSBob3BlIHRvIHNlZSBzb21lIHJlc3BvbnNlLg0KDQpC ZXN0IFJlZ2FyZHMsDQpOb2JvICYgTWFyYw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1heSAwNywgMjAxMyAxMjowOSBQTQ0KVG86IE1hcmMg QmluZGVyYmVyZ2VyIChtYmluZGVyYik7IE5vYm8gQWtpeWEgKG5vYm8pDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1iaW5kLWJmZC1yZWR1bmRhbmN5LTAxLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYmluZC1iZmQtcmVkdW5kYW5jeS0w MS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFyYyBCaW5kZXJiZXJn ZXIgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFm dC1tYmluZC1iZmQtcmVkdW5kYW5jeQ0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgUmVkdW5kYW50 IEJGRCBzZXNzaW9ucw0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDUtMDcNCkdyb3VwOgkJIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQpVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1iaW5kLWJmZC1yZWR1bmRh bmN5LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LW1iaW5kLWJmZC1yZWR1bmRhbmN5DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1iaW5kLWJmZC1yZWR1bmRhbmN5LTAxDQpEaWZmOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1iaW5kLWJm ZC1yZWR1bmRhbmN5LTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEg c2Vjb25kIG9yICJzaGFkb3ciIEJGRCBzZXNzaW9uIHRvIGFuIGV4aXN0aW5nDQogICAicHJpbWFy eSIgQkZEIHNlc3Npb24sIHByb3ZpZGluZyByZXNpbGllbmN5IGFnYWluc3QgQkZEIGZhaWx1cmVz IHRoYXQNCiAgIGFyZSBub3QgbGVnaXRpbWF0ZS4NCg0KICAgU2NlbmFyaW9zIHdpbGwgYmUgZGlz Y3Vzc2VkIG9uIGhvdyBwcmVzZW5jZSBvZiBhIHNoYWRvdyBCRkQgc2Vzc2lvbg0KICAgd2lsbCBi ZSBiZW5lZmljaWFsIGluIHRoZSBjb250ZXh0IG9mIGhpZ2ggYXZhaWxhYmlsaXR5Lg0KDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From jhaas@slice.pfrc.org Wed May 8 10:18:29 2013 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 484CF21F8F05 for ; Wed, 8 May 2013 10:18:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvq2Q7Eb8f3X for ; Wed, 8 May 2013 10:18:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 394EC21F8EDF for ; Wed, 8 May 2013 10:18:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A08E0C25D; Wed, 8 May 2013 13:18:24 -0400 (EDT) Date: Wed, 8 May 2013 13:18:24 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: KARP analysis of BFD Message-ID: <20130508171824.GE12732@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 08 May 2013 17:18:29 -0000 For those of you who aren't following KARP: http://tools.ietf.org/html/draft-ietf-karp-bfd-analysis-00 I believe the primary fallout from the analysis is roughly this: * draft-ietf-bfd-generic-crypto-auth (already a WG document) covers the increased sequence number key space. * draft-ietf-bfd-hmac-sha (already a WG document) covers the ciphers. Procedurally, some additional randomization of discriminator values is recommended as well. The BFD base specification already recommends that it be set to a random value for increased security. (I.e. check your implementations.) Echo mode security considerations are already outside the scope of the BFD protocol. If you use it, consider your security. -- Jeff From adrian@olddog.co.uk Tue May 7 10:10:41 2013 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 955C921F88EA for ; Tue, 7 May 2013 10:10:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E8VL51D1xBz for ; Tue, 7 May 2013 10:10:37 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A6FFA21F884F for ; Tue, 7 May 2013 10:10:36 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47HAZSb020323 for ; Tue, 7 May 2013 18:10:35 +0100 Received: from 950129200 (no-reverse-dns.mlnet.ie [31.216.236.149] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47HAYnL020310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 7 May 2013 18:10:35 +0100 From: "Adrian Farrel" To: "Adrian Farrel" References: In-Reply-To: Subject: FW: Retiring ACH TLVs Date: Tue, 7 May 2013 18:10:31 +0100 Message-ID: <003201ce4b45$c87831f0$596895d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkAAADPGg Content-Language: en-gb X-Mailman-Approved-At: Fri, 10 May 2013 08:15:09 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:10:41 -0000 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 07 May 2013 18:09 > To: mpls@ietf.org > Subject: Retiring ACH TLVs >=20 > Hi, >=20 > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it = is about > explaining why no-one actually wants to use them (i.e., when each new = ACH > Type is defined and has a "No TLVs" written for it, we get asked "why = not?"). >=20 > It seems to us that ACH TLVs are an idea that has been rejected. = Initially we > thought they might be used (especially for identifiers), but there = seems to be > good opinion that handling generic TLVs would be a pain. >=20 > Since I was heavily responsible for insisting that ACH TLVs were = included in RFC > 5586, it seems reasonable that I do the work to fix it. >=20 > The I-D below retires ACH TLVs and handles the necessary registry = changes. >=20 > Note, of course, that structured data are still possible within = individual ACHs if the > protocol spec for an individual ACH decides to have them. >=20 > We're directing this work to the MPLS working group because that is = where 5586 > was written. I have BCC'ed PWE3, L2VPN, and BFD for information. >=20 > Thanks for any comments. >=20 > As humble WG contributors we would be enthusiastic to see early WG = adoption > and last call :-) >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 07 May 2013 17:33 > > To: Adrian Farrel; Stewart Bryant > > Subject: New Version Notification for = draft-farbryantrel-mpls-retire-ach-tlv- > > 00.txt > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > Revision: 00 > > Title: Retiring TLVs from the Associated Channel Header of the = MPLS > > Generic Associated Channel > > Creation date: 2013-05-07 > > Group: Individual Submission > > Number of pages: 4 > > URL: = http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > ach-tlv-00.txt > > Status: = http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach- > tlv > > Htmlized: = http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv- > 00 > > > > > > Abstract: > > The MPLS Generic Associated Channel (G-ACh) is a generalization = of > > the applicability of the Pseudowire (PW) Associated Channel = Header > > (ACH). RFC 5586 defines the concept of Type-Length-Variable = (TLV) > > constructs that can be carried in messages on the G-ACh by = placing > > them in the ACH. > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, = it > > is believed that handling TLVs in hardware introduces significant > > problems to the fast-path, and since G-ACh messages are intended = to > > be processed substantially in hardware, the use of TLVs in > > undesirable. > > > > This document updates RFC 5586 by retiring ACH TLVs and removing = the > > associated registry. > > > > > > > > > > The IETF Secretariat From jhaas@slice.pfrc.org Fri May 10 08:24:00 2013 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 7E0DE21F8CEC for ; Fri, 10 May 2013 08:23:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Meju8C3TGbMd for ; Fri, 10 May 2013 08:23:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A490A21F8C35 for ; Fri, 10 May 2013 08:23:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 119CEC27A; Fri, 10 May 2013 11:23:36 -0400 (EDT) Date: Fri, 10 May 2013 11:23:36 -0400 From: Jeffrey Haas To: Lokesh NB Subject: Re: How commonly Echo and Demand mode is used? Message-ID: <20130510152336.GT12732@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 10 May 2013 15:24:00 -0000 [somewhat stale question] On Fri, Apr 05, 2013 at 10:21:45AM +0530, Lokesh NB wrote: > I would like know if there are routing applications that use demand mode > and echo mode usually. > I understand that asynchronous mode is used by most of the applications. > I'm newbie to BFD, sorry if these questions sound too naive. Appreciate > answers. I'm unclear about support of demand mode in the industry. At least one vendor implements echo mode. If we're feeling energetic as a working group, BFD is well deployed enough that we can gather the implementation reports for the core RFCs and move forward with bumping BFD up in the standards track. -- Jeff From jhaas@slice.pfrc.org Fri May 10 09:19:53 2013 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 2B42221F8556 for ; Fri, 10 May 2013 09:19:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhbcQM6Lp1P0 for ; Fri, 10 May 2013 09:19:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0999B21F859B for ; Fri, 10 May 2013 09:19:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 75B0EC27A; Fri, 10 May 2013 12:19:48 -0400 (EDT) Date: Fri, 10 May 2013 12:19:48 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: New Version Notification for draft-mbind-bfd-redundancy-01.txt Message-ID: <20130510161948.GV12732@pfrc> References: <20130507160834.23471.66090.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 10 May 2013 16:19:53 -0000 [Speaking as an individual contributor.] Nobo, Marc, On Tue, May 07, 2013 at 04:15:48PM +0000, Nobo Akiya (nobo) wrote: > Hello BFD WG Members, > > Marc and myself have just rolled out rev -01 of BFD redundancy draft. > > Some minor changes throughout the document, but core changes are: > > (1) Section 2 has been re-written to better describe use case scenarios. > (2) Section 7 has been added to describe how the mechanism works for LSP ping bootstrapped sessions. > > We believe that this revision makes better reading material over coffee, and we hope to see some response. > > Best Regards, > Nobo & Marc [...] > URL: http://www.ietf.org/internet-drafts/draft-mbind-bfd-redundancy-01.txt I just had a chance to read through this draft. I think the use cases are nicely stated. Some comments on the draft. Encoding: Version numbers are *not* a good way for us to look at extending BFD as a whole. We don't have much of a space for such things. For what it's worth, Dave and I previously had some discussions about ways to piggy-back additional data into BFD in the existing 5880 standard, but we've avoided it every single time thus far. Keeping in mind the underlying principles of BFD, let's keep the protocol simple if possible and let the applications make rich use of it. Making use of distinct discriminators for the sessions lets us do this, and should we pursue this draft, that would be my vote. While the base BFD specification encourages sharing the same session between common endpoints, it doesn't preclude multiple sessions. (And to some extent, that's what we're doing for BFD over LAG - multiple sessions covering a single endpoint.) What becomes the interesting problem with multiple sessions is use of this information by the application (e.g. BGP). It would be necessary for both sides of the connection to negotiate more than a single session and bind the fate of the applications to the associated set of sessions. In the absence of both sides being aware that multiple sessions are involved (i.e. one side is an existing BFD v1 speaker expecting a single session), the side expecting a single session wouldn't use multiple sessions for fate-sharing purposes. In other words, regardless of packet format or multiple sessions, the important thing is that the applications themselves know to use multiple sessions. Multiple sessions and arcane failures: The covered use cases presume some failure of the BFD speaker in the associated device. There are a few additional scenarios that make multiple sessions themselves somewhat problematic: - The additional session doesn't share enough fate with the forwarding for the application (e.g. routing) for its input to be valid. Such an analysis obviously will be vendor and implementation dependent. - An interesting bit of complexity in requesting an additional session is also figuring out how to ask the remote side to associate that session with a particular resource such as a line card, main CPU, etc. For example, if session 1 on router A is bound to a line card and bound to router B's main CPU, are you really monitoring what you thought? Detection intervals: You cover this to some extent in your draft under "Scale aspect". A major implication of multiple sessions is that timing is likely to be less granular on one session. You thus potentially gain resiliency to some faults at the cost of a longer detection interval. ------ IMO, it's worth continuing to discuss the uses cases and possible mechanisms for this draft. However, I'd encourage the implementation to focus on the application bootstrapping considerations for multiple sessions rather than trying to add this to the packet format. -- Jeff From jhaas@slice.pfrc.org Fri May 10 10:24:47 2013 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 556B221F8E6E; Fri, 10 May 2013 10:24:47 -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=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5i21cFT1Qb6; Fri, 10 May 2013 10:24:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2621F8E62; Fri, 10 May 2013 10:24:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2D96CC27A; Fri, 10 May 2013 13:24:41 -0400 (EDT) Date: Fri, 10 May 2013 13:24:41 -0400 From: Jeffrey Haas To: Sam Aldrin Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 Message-ID: <20130510172441.GB12732@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Santiago Alvarez \(saalvare\)" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" , "mpls@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, 10 May 2013 17:24:47 -0000 On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > I echo what Santiago had said in his email. Good to have an informational document and do not support the idea of standardizing the intervals. Speaking as chair, while I'm not in favor of have a standardized set of intervals (the fights such a document would create would be epic), I am highly supportive of such a document having informational status. As a suggestion, there may be two actual documents in such a case: - An informational document covering the intervals. - A short document, potentially on the standards track, covering the procedure by which timers can negotiate to such an interval. This may be worth standardizing. (This is covered by Appendix B.) -- Jeff From nobo@cisco.com Fri May 10 13:47:53 2013 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 159FA21F92EC for ; Fri, 10 May 2013 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eieC4cSrMZzT for ; Fri, 10 May 2013 13:47:47 -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 A624B21F92C2 for ; Fri, 10 May 2013 13:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6384; q=dns/txt; s=iport; t=1368218867; x=1369428467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wpQycCxB13WAp5Q23H1Gckyty5ThRYA+EfHiQc92jLg=; b=ST2qDEt9l80+ZT/RKm4JdAtxStPR9Zn24wu6GxvNKu2GpnuVcRQulte8 ovIJNqA9OwMzdCN1b2v6izm6tHuiCksOnKC4DYlh0yigfcweuF+VyFgFy QG+3nDPtygBz6/q6n6G3xt8T+ZBdtoJercFgaXP2Va1ZQjPa/G6ud/qeG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAB5cjVGtJXG8/2dsb2JhbABSgmYhwFR8FnSCHwEBAQMBOjIKAQIFCwIBCA4UFBAyJQIEDg0Th2sGAb0/jWWBEjEHgnRhA5NdlQSDD4In X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="206013884" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 10 May 2013 20:47:47 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4AKlk6k016519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 20:47:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 10 May 2013 15:47:46 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: New Version Notification for draft-mbind-bfd-redundancy-01.txt Thread-Topic: New Version Notification for draft-mbind-bfd-redundancy-01.txt Thread-Index: AQHOSz0jrSNBtybugkWJoRqk1+vF7Zj54/DQgAUNyQD//+krMA== Date: Fri, 10 May 2013 20:47:46 +0000 Message-ID: References: <20130507160834.23471.66090.idtracker@ietfa.amsl.com> <20130510161948.GV12732@pfrc> In-Reply-To: <20130510161948.GV12732@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 10 May 2013 20:47:53 -0000 Hello Jeff, Many thought provoking responses, thank you! > Encoding: > Version numbers are *not* a good way for us to look at extending BFD as a > whole. We don't have much of a space for such things. For what it's wor= th, > Dave and I previously had some discussions about ways to piggy-back > additional data into BFD in the existing 5880 standard, but we've avoided= it > every single time thus far. Keeping in mind the underlying principles of > BFD, let's keep the protocol simple if possible and let the applications = make > rich use of it. What you and Dave had discussed in past regarding "piggy-back" will be an v= ery interesting topic itself ... perhaps you can share one of these days :) Yes I agree with the "simple" philosophy of BFD. I believe there are two as= pects to this. (1) Keep BFD a simple protocol. (2) Keep BFD a simple protocol to use. We definitely should keep BFD a simple protocol, but at the same time, I be= lieve it will be beneficial to keep BFD a simple protocol to use, to promot= e rich use. >=20 > Making use of distinct discriminators for the sessions lets us do this, a= nd > should we pursue this draft, that would be my vote. While the base BFD > specification encourages sharing the same session between common > endpoints, it doesn't preclude multiple sessions. (And to some extent, > that's what we're doing for BFD over LAG - multiple sessions covering a > single > endpoint.) Yes BFD over LAG is similar in some way. Micro sessions, fortunately, had d= istinct in/out interfaces to [de]mux. Distinct discriminators will be nice = & clean. Tricky aspect is that we need distinct [de]mux "variable" in order= to have distinct discriminators. UDP ports are not preferred since we woul= d then need to come up different mechanism for IP-less sessions from. So th= e initial [de]muxer was exactly what Marc and I had problem with, and we we= re only left with option (a) and (b) from the documents. Sometimes I wish t= here were more "lego pieces" :) =20 >=20 > What becomes the interesting problem with multiple sessions is use of thi= s > information by the application (e.g. BGP). It would be necessary for bot= h > sides of the connection to negotiate more than a single session and bind = the > fate of the applications to the associated set of sessions. In the absen= ce of > both sides being aware that multiple sessions are involved (i.e. one side= is > an existing BFD v1 speaker expecting a single session), the side expectin= g a > single session wouldn't use multiple sessions for fate-sharing purposes. = In > other words, regardless of packet format or multiple sessions, the > important thing is that the applications themselves know to use multiple > sessions. I see that it's possible to absorb this logic in BFD. Document provides rul= es to consolidate the state. Final state is UP when the state of the primary session is UP or the state of the shadow session is UP. Final state is DOWN when both the state primary session is DOWN and the state of the shadow sessions is DOWN. Even with one side being only v1 speaker, v1/v2 speaker side can produce co= rrect final state to applications. >=20 > Multiple sessions and arcane failures: > The covered use cases presume some failure of the BFD speaker in the > associated device. There are a few additional scenarios that make multip= le > sessions themselves somewhat problematic: > - The additional session doesn't share enough fate with the forwarding fo= r > the application (e.g. routing) for its input to be valid. Such an > analysis obviously will be vendor and implementation dependent. Yes. > - An interesting bit of complexity in requesting an additional session is > also figuring out how to ask the remote side to associate that session > with a particular resource such as a line card, main CPU, etc. For > example, if session 1 on router A is bound to a line card and bound to > router B's main CPU, are you really monitoring what you thought? Interesting. Right now, I see the placement of two sessions is strictly loc= al matter. In other words, if router A notices that router B has primary/sh= adow, then router A should assume that router B has placed the two sessions= in optimal locations. >=20 > Detection intervals: > You cover this to some extent in your draft under "Scale aspect". A majo= r > implication of multiple sessions is that timing is likely to be less gran= ular on > one session. You thus potentially gain resiliency to some faults at the = cost > of a longer detection interval. Correct. If a system has max BFD provisioned, then v2 can only be introduce= d at the cost of stealing v1 resources. This is the unfortunate drawback. B= ut even with this cost, I believe resiliency can bring benefits ... based o= n my guess of many production routers not max'ing out BFD resources. In add= ition, on centralized BFD, shared resources required to run shadows in seco= ndary route processor may be smaller. So some aspects of this is implementa= tion specific.=20 >=20 > ------ >=20 > IMO, it's worth continuing to discuss the uses cases and possible > mechanisms for this draft.=20 I'm happy to see this statement, thank you :) > However, I'd encourage the implementation to > focus on the application bootstrapping considerations for multiple sessio= ns > rather than trying to add this to the packet format. Proposed solution is what Marc and I thought as best at the time being. We = also understand that this problem & solution falls in the gray zone between= implementation vs. standard. We also _also_ believe that, due to aggressiv= e nature of BFD, simple and consistent solution will be beneficial to vendo= rs & end-users, but that can only be achieved if there was a standard. For = those reasons, I would like to ensure, if this draft progresses, that outco= me is indeed something simple and consistent, and is beneficial to _many_ v= endors and _many_ end-users. To conclude: - We welcome more comments from vendors and end-users. - Need more thought on how to use distinct discriminators for primary/shado= w, if that's possible. If not, is usage of v2 is the right mechanism? Regards, Nobo >=20 > -- Jeff From nobo@cisco.com Fri May 10 15:06:31 2013 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 7812D21F909A; Fri, 10 May 2013 15:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXYb2cwBx6Gr; Fri, 10 May 2013 15:06:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8521F8FF1; Fri, 10 May 2013 15:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1368223586; x=1369433186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kZmq7trb6vqPwOKuUIXPa9nv4Q4n618d1eXhEjA1jWc=; b=e3gHnH/7kR03lWGZhMx0zAO6R3CpB5goTeVhvvsbdemRBSeaSIFzsSQj viwPpGvgYkhfOV8HcDI3nP1FulY9WYT8HaRRc3X20ywr2nMz4o0nZv1OQ 59Ihq1v64r5zhJgGbRLWYL1J6byssQBhxwRQWB0UI503PBHu3cqbprhoU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALBujVGtJXG8/2dsb2JhbABSgmYhN8AgfBZ0gh8BAQEDAQEBATc0CwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCId+BgELvTcEjVsLgRExBwaCbmEDqGGDD4FyNQ X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208981369" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 10 May 2013 22:06:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4AM6P00006170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 22:06:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 10 May 2013 17:06:24 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , Sam Aldrin Subject: RE: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Topic: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAy8rAAAAN+FAAAAiuEAAAAzaYAfAr3RgAABGsbw Date: Fri, 10 May 2013 22:06:23 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> In-Reply-To: <20130510172441.GB12732@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Santiago Alvarez \(saalvare\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" , "pwe3@ietf.org" , "mpls@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, 10 May 2013 22:06:31 -0000 Hello Jeff, Sam, Santiago, > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may = be > worth standardizing. (This is covered by Appendix B.) Thanks for comments & make sense. Marc and I will take this offline (potent= ially pull in some folks) and further discuss next steps. Regards, Nobo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Jeffrey Haas > Sent: Friday, May 10, 2013 1:25 PM > To: Sam Aldrin > Cc: Santiago Alvarez (saalvare); rtg-bfd@ietf.org; pwe3@ietf.org; > mpls@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >=20 > On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > > I echo what Santiago had said in his email. Good to have an information= al > document and do not support the idea of standardizing the intervals. >=20 > Speaking as chair, while I'm not in favor of have a standardized set of > intervals (the fights such a document would create would be epic), I am > highly supportive of such a document having informational status. >=20 > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may = be > worth standardizing. (This is covered by Appendix B.) >=20 > -- Jeff > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Fri May 10 15:13:45 2013 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 0967E21F9428; Fri, 10 May 2013 15:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVRkszF+sRtT; Fri, 10 May 2013 15:13:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 959A021F941F; Fri, 10 May 2013 15:13:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> Date: Fri, 10 May 2013 15:13:44 -0700 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, 10 May 2013 22:13:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Bidirectional Forwarding Detection (BFD) on Link Aggrega= tion Group (LAG) Interfaces Author(s) : Manav Bhatia Mach(Guoyi) Chen Sami Boutros Marc Binderberger Jeffrey Haas Filename : draft-ietf-bfd-on-lags-00.txt Pages : 11 Date : 2013-05-10 Abstract: This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhaas@slice.pfrc.org Fri May 10 15:16:27 2013 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 8515321F8F6E for ; Fri, 10 May 2013 15:16:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiJocZhiW8gX for ; Fri, 10 May 2013 15:16:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7431B21F901B for ; Fri, 10 May 2013 15:16:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 17A77C27A; Fri, 10 May 2013 18:16:23 -0400 (EDT) Date: Fri, 10 May 2013 18:16:23 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Message-ID: <20130510221623.GF12732@pfrc> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 10 May 2013 22:16:27 -0000 Finally, we have the draft as draft-ietf-bfd! The draft represents consensus to date. Please give the document some of your time for review. Also, authors, please make a positive acknowledgement to the mailing list as to whether you are aware of any IPR against this draft. -- Jeff On Fri, May 10, 2013 at 03:13:44PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. > > Title : Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces > Author(s) : Manav Bhatia > Mach(Guoyi) Chen > Sami Boutros > Marc Binderberger > Jeffrey Haas > Filename : draft-ietf-bfd-on-lags-00.txt > Pages : 11 > Date : 2013-05-10 > > Abstract: > This document proposes a mechanism to run BFD on Link Aggregation > Group (LAG) interfaces. It does so by running an independent > Asynchronous mode BFD session on every LAG member link. > > This mechanism allows the verification of member link continuity, > either in combination with, or in absence of, LACP. It provides a > shorter detection time than what LACP offers. The continuity check > can also cover elements of layer 3 bidirectional forwarding. > > This mechanism utilizes a well-known UDP port distinct from that of > single-hop BFD over IP. This new UDP port removes the ambiguity of > BFD over LAG packets from BFD over single-hop IP. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From wim.henderickx@alcatel-lucent.com Fri May 10 23:46:03 2013 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 5124721F848A for ; Fri, 10 May 2013 23:46:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIlGn5pOMxGu for ; Fri, 10 May 2013 23:45:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7162821F8F11 for ; Fri, 10 May 2013 23:45:45 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4B6jf50012352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 11 May 2013 01:45:42 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4B6jfWu011811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 May 2013 02:45:41 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 11 May 2013 02:45:41 -0400 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sat, 11 May 2013 08:45:38 +0200 From: "Henderickx, Wim (Wim)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Topic: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Index: AQHOTcuz1lCPXQ3iQ0mw8wLwFq4oqpj+2uSAgADAj4A= Date: Sat, 11 May 2013 06:45:37 +0000 Message-ID: In-Reply-To: <20130510221623.GF12732@pfrc> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Sat, 11 May 2013 06:46:03 -0000 I am not aware of IPR against this draft On 11/05/13 00:16, "Jeffrey Haas" wrote: >Finally, we have the draft as draft-ietf-bfd! > >The draft represents consensus to date. Please give the document some of >your time for review. > >Also, authors, please make a positive acknowledgement to the mailing list >as >to whether you are aware of any IPR against this draft. > >-- Jeff > >On Fri, May 10, 2013 at 03:13:44PM -0700, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Bidirectional Forwarding Detection >>Working Group of the IETF. >>=20 >> Title : Bidirectional Forwarding Detection (BFD) on Link >>Aggregation Group (LAG) Interfaces >> Author(s) : Manav Bhatia >> Mach(Guoyi) Chen >> Sami Boutros >> Marc Binderberger >> Jeffrey Haas >> Filename : draft-ietf-bfd-on-lags-00.txt >> Pages : 11 >> Date : 2013-05-10 >>=20 >> Abstract: >> This document proposes a mechanism to run BFD on Link Aggregation >> Group (LAG) interfaces. It does so by running an independent >> Asynchronous mode BFD session on every LAG member link. >>=20 >> This mechanism allows the verification of member link continuity, >> either in combination with, or in absence of, LACP. It provides a >> shorter detection time than what LACP offers. The continuity check >> can also cover elements of layer 3 bidirectional forwarding. >>=20 >> This mechanism utilizes a well-known UDP port distinct from that of >> single-hop BFD over IP. This new UDP port removes the ambiguity of >> BFD over LAG packets from BFD over single-hop IP. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ From marc@sniff.de Sat May 11 11:52:47 2013 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 950AF21F870F for ; Sat, 11 May 2013 11:52:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X68SV0kFllsI for ; Sat, 11 May 2013 11:52:46 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01E21F866E for ; Sat, 11 May 2013 11:52:45 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8F9582AA0F; Sat, 11 May 2013 18:52:42 +0000 (GMT) Subject: Re: New Version Notification for draft-mbind-bfd-redundancy-01.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20130510161948.GV12732@pfrc> Date: Sat, 11 May 2013 20:52:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24970501-D0DE-4CF6-A8B5-E1B23C016B7C@sniff.de> References: <20130507160834.23471.66090.idtracker@ietfa.amsl.com> <20130510161948.GV12732@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) Cc: Marc Binderberger , 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, 11 May 2013 18:52:47 -0000 Hello Jeff, thanks for the detailed feedback. Let me comment on some key aspects: > What becomes the interesting problem with multiple sessions is use of = this > information by the application (e.g. BGP). and > However, I'd encourage the implementation to focus on the > application bootstrapping considerations for multiple sessions rather = than > trying to add this to the packet format. This is where we have a directly opposed opinion. While I don't mind to = provide the primary/shadow information details to the application if the = application wants to know I am fairly sure that most applications do = _not_ want to know. Applications like BGP "buy an liveliness service" = from BFD; there is no interest from BGP to have exposure to BFD-internal = challenges. Nor do I think using application protocols as out-of-band = to bootstrap BFD is a preferable design (sometimes you cannot avoid it, = true), it makes things complex. > Version numbers are *not* a good way for us to look at extending BFD = as a > whole. We don't have much of a space for such things. Partially agree. The version number space is limited but looking at the = rate we use version numbers I don't see this as a problem per se. > Keeping in mind the underlying principles of > BFD, let's keep the protocol simple if possible and let the = applications > make rich use of it. That's why we tried to keep the packet layout the same. The packet = engine remains the same, except the filter for v=3D2 (or v=3D1,2) = instead of v=3D1.=20 > Making use of distinct discriminators for the sessions lets us do = this, and > should we pursue this draft, that would be my vote. Once the session is Init or Up you are right. Problem is to bootstrap = it. We do not plan for out-of-band signalling unless this is used = already for "primary" sessions, e.g. RFC5884 BFD over LSPs, to avoid = complexity. Thus we need to separate the primary Down from the shadow Down packets. = All the fields and bits are used already. The version field has the = interesting property that an implementation only supporting v1 would (or = should) simply drop the shadow packets. Could we use discriminators ... I admit I ruled this out as we have only = zero as a reserved value, otherwise it's up to the implementation how it = assigns the value and the peer just reflects the discriminator back. We = could start to define additional reserved discriminator values, e.g. = 0xFFFFFFFF as the "shadow zero" but the problem remains that a v1-only = implementation may see this discriminator value as a valid one (i.e. = it's in use). > - An interesting bit of complexity in requesting an additional session = is > also figuring out how to ask the remote side to associate that = session > with a particular resource such as a line card, main CPU, etc. For > example, if session 1 on router A is bound to a line card and bound = to > router B's main CPU, are you really monitoring what you thought? I think Nobo answered this already: every implementation optimizes = locally, i.e. tries to make it as resilient/redundant as it can. In this = example at least A protects against a linecard failure with the help of = B. For B, if there is only one CPU there is not much we can do but B at = least can support A's effort by supporting shadow sessions. There will be many discussions following, I'm sure ;-) Regards, Marc On 2013-05-10, at 18:19 , Jeffrey Haas wrote: > [Speaking as an individual contributor.] >=20 > Nobo, Marc, >=20 > On Tue, May 07, 2013 at 04:15:48PM +0000, Nobo Akiya (nobo) wrote: >> Hello BFD WG Members, >>=20 >> Marc and myself have just rolled out rev -01 of BFD redundancy draft. >>=20 >> Some minor changes throughout the document, but core changes are: >>=20 >> (1) Section 2 has been re-written to better describe use case = scenarios. >> (2) Section 7 has been added to describe how the mechanism works for = LSP ping bootstrapped sessions. >>=20 >> We believe that this revision makes better reading material over = coffee, and we hope to see some response. >>=20 >> Best Regards, >> Nobo & Marc > [...] >> URL: = http://www.ietf.org/internet-drafts/draft-mbind-bfd-redundancy-01.txt >=20 > I just had a chance to read through this draft. I think the use cases = are > nicely stated. Some comments on the draft. >=20 > Encoding: > Version numbers are *not* a good way for us to look at extending BFD = as a > whole. We don't have much of a space for such things. For what it's = worth, > Dave and I previously had some discussions about ways to piggy-back > additional data into BFD in the existing 5880 standard, but we've = avoided it > every single time thus far. Keeping in mind the underlying principles = of > BFD, let's keep the protocol simple if possible and let the = applications > make rich use of it. >=20 > Making use of distinct discriminators for the sessions lets us do = this, and > should we pursue this draft, that would be my vote. While the base = BFD > specification encourages sharing the same session between common = endpoints, > it doesn't preclude multiple sessions. (And to some extent, that's = what > we're doing for BFD over LAG - multiple sessions covering a single > endpoint.) >=20 > What becomes the interesting problem with multiple sessions is use of = this > information by the application (e.g. BGP). It would be necessary for = both > sides of the connection to negotiate more than a single session and = bind the > fate of the applications to the associated set of sessions. In the = absence > of both sides being aware that multiple sessions are involved (i.e. = one side > is an existing BFD v1 speaker expecting a single session), the side > expecting a single session wouldn't use multiple sessions for = fate-sharing > purposes. In other words, regardless of packet format or multiple = sessions, > the important thing is that the applications themselves know to use = multiple > sessions. >=20 > Multiple sessions and arcane failures: > The covered use cases presume some failure of the BFD speaker in the > associated device. There are a few additional scenarios that make = multiple > sessions themselves somewhat problematic: > - The additional session doesn't share enough fate with the forwarding = for > the application (e.g. routing) for its input to be valid. Such an > analysis obviously will be vendor and implementation dependent. > - An interesting bit of complexity in requesting an additional session = is > also figuring out how to ask the remote side to associate that = session > with a particular resource such as a line card, main CPU, etc. For > example, if session 1 on router A is bound to a line card and bound = to > router B's main CPU, are you really monitoring what you thought? >=20 > Detection intervals: > You cover this to some extent in your draft under "Scale aspect". A = major > implication of multiple sessions is that timing is likely to be less > granular on one session. You thus potentially gain resiliency to some > faults at the cost of a longer detection interval. >=20 > ------ >=20 > IMO, it's worth continuing to discuss the uses cases and possible = mechanisms > for this draft. However, I'd encourage the implementation to focus on = the > application bootstrapping considerations for multiple sessions rather = than > trying to add this to the packet format. >=20 > -- Jeff >=20 From jeff.tantsura@ericsson.com Sat May 11 13:07:06 2013 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 D2C2C21F881F for ; Sat, 11 May 2013 13:07:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXh1-5i7HJ0r for ; Sat, 11 May 2013 13:07:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E80C921F87B1 for ; Sat, 11 May 2013 13:07:00 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-1c-518ea4e35eae Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6D.E8.26377.4E4AE815; Sat, 11 May 2013 22:07:00 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sat, 11 May 2013 16:06:59 -0400 From: Jeff Tantsura To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Topic: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Index: AQHOTcu+UC/z5FX4F0mf6y+gXQKs/Jj/P3mAgAD44IA= Date: Sat, 11 May 2013 20:06:59 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483935FDC9@eusaamb109.ericsson.se> In-Reply-To: <20130510221623.GF12732@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyuXRPlO6TJX2BBq37JCz2H3zLavH5zzZG ByaPJUt+Mnlc7t3KGsAUxWWTkpqTWZZapG+XwJWxpPMkU8FDoYopB34yNTBO5eti5OSQEDCR OLxuBQuELSZx4d56ti5GLg4hgaOMEttXbmSCcJYzSpw50ssEUsUmYCDx/9txsA4RAQ+J7mPP GUFsYQEziV2fHrJDxM0ldiz/xgRhW0ks/3WOFcRmEVCVeNk+iRnE5hXwlnh48xXYHE4BLYlH y46C1TMCXfH91Bowm1lAXOLWk/lMENcJSCzZc54ZwhaVePn4H9hMUQE9ibZjZ9gh4soSS57s Z4Ho1ZFYsPsTG4RtLXFq21VmCFtbYtnC11A3CEqcnPmEZQKj2Cwk62YhaZ+FpH0WkvZZSNoX MLKuYuQoLU4ty003MtjECIyfYxJsujsY97y0PMQozcGiJM4bxdUYKCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoGRY9n3szsqsmZtm8NVOHNHQ6mvYHXfFqd/M7w2Xjl2Ya34i507Jh6ZJmTu ZXj3woEXNS/PhXTKeB723quZ8vylr4BOiE/Ji20HrV7efN70VOjHz1XH21WNrWVft7g9tz3O +TB/aThn6zmDPUVzeX8uX7+/2Lj7lehJ0+k5ocpbXW9dU36w+gfbWSWW4oxEQy3mouJEACue ngttAgAA 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, 11 May 2013 20:07:06 -0000 Hi, I'm not aware of any IPR. Thanks! Cheers, Jeff -----Original Message----- From: Jeffrey Haas Date: Friday, May 10, 2013 3:16 PM To: "rtg-bfd@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt >Finally, we have the draft as draft-ietf-bfd! > >The draft represents consensus to date. Please give the document some of >your time for review. > >Also, authors, please make a positive acknowledgement to the mailing list >as >to whether you are aware of any IPR against this draft. > >-- Jeff > >On Fri, May 10, 2013 at 03:13:44PM -0700, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Bidirectional Forwarding Detection >>Working Group of the IETF. >>=20 >> Title : Bidirectional Forwarding Detection (BFD) on Link >>Aggregation Group (LAG) Interfaces >> Author(s) : Manav Bhatia >> Mach(Guoyi) Chen >> Sami Boutros >> Marc Binderberger >> Jeffrey Haas >> Filename : draft-ietf-bfd-on-lags-00.txt >> Pages : 11 >> Date : 2013-05-10 >>=20 >> Abstract: >> This document proposes a mechanism to run BFD on Link Aggregation >> Group (LAG) interfaces. It does so by running an independent >> Asynchronous mode BFD session on every LAG member link. >>=20 >> This mechanism allows the verification of member link continuity, >> either in combination with, or in absence of, LACP. It provides a >> shorter detection time than what LACP offers. The continuity check >> can also cover elements of layer 3 bidirectional forwarding. >>=20 >> This mechanism utilizes a well-known UDP port distinct from that of >> single-hop BFD over IP. This new UDP port removes the ambiguity of >> BFD over LAG packets from BFD over single-hop IP. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ From glen.kent@gmail.com Sun May 12 11:52:11 2013 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 A59D321F87C5 for ; Sun, 12 May 2013 11:52: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F57kgEaBchL for ; Sun, 12 May 2013 11:52:06 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 82E7121F86CE for ; Sun, 12 May 2013 11:52:06 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id k14so5244229oag.36 for ; Sun, 12 May 2013 11:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=iOBGt4viCa8G5s8kwHvk7uAg802WppaCwf+HFjJ9HKI=; b=iw0K63NVHLPcPsp+2fKt04GU39ncCJST3xSBNRfdmrBC/QpFTQD5sFeBqoU3mBr0ij qQ8OwT6IAb2cU5km9mcrkN7SgiktYaHtv/vBfKH1lRNMAqBvOio91oByRlidNheppvz/ mXtxgAxlyeFh+cTETK+WLJnyO+6F2OdQTbepoOOCY5GJoiQxA47VWpmjgUupo0cGxa0N 0Tl+8F4F5zJtW1kEYMcqAAFj07+8/0hkeASqv0oTD9bDvyM1LcuoAnxsaDSeFIMB+AYQ qY6Ai+UN4B67vu9zsw4U4WF/xmgPw7rvO72Ob7heS39xfV+48mFZ3XqLMPg+1TinvYfR 5Hag== MIME-Version: 1.0 X-Received: by 10.60.174.72 with SMTP id bq8mr11564374oec.123.1368384720514; Sun, 12 May 2013 11:52:00 -0700 (PDT) Received: by 10.182.236.105 with HTTP; Sun, 12 May 2013 11:52:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 May 2013 00:22:00 +0530 Message-ID: Subject: Re: few queries regarding BFD From: Glen Kent To: Binny Jeshan , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=089e01228a442eb4ac04dc89e5db 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, 12 May 2013 18:52:11 -0000 --089e01228a442eb4ac04dc89e5db Content-Type: text/plain; charset=ISO-8859-1 Authentication is never used to hide information in the routing protocols. Its always used to authenticate the sender of the protocol packet. Usually, its configured only to detect misconfigured peers. Since BFD is a fast protocol and is often implemented in HW, getting authentication to work is complex. This i believe is the primary reason why the authentication related drafts in BFD WG have still not progressed. 6. Cannot comment anything solid again. Auth is used if you need to hide > your information. You may not get exact answers in this forum :( > > Thanks, > Binny Jeshan. > > Glen --089e01228a442eb4ac04dc89e5db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Authentication is never used to hide information in the ro= uting protocols.

Its always used to authenticate the sen= der of the protocol packet. Usually, its configured only to detect misconfi= gured peers. Since BFD is a fast protocol and is often implemented in HW, g= etting authentication to work is complex. This i believe is the primary rea= son why the authentication related drafts in BFD WG have still not progress= ed.


6. Canno= t comment anything solid again. Auth is used if you need to hide your infor= mation. You may not get exact answers in this forum :(

Thanks,
Binny Jeshan.


Glen

--089e01228a442eb4ac04dc89e5db-- From jhaas@slice.pfrc.org Sun May 12 12:00:00 2013 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 1E18221F85ED for ; Sun, 12 May 2013 12:00:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7waAM2CQ-NVS for ; Sun, 12 May 2013 11:59:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 194F121F882A for ; Sun, 12 May 2013 11:59:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 83AC5C4EE; Sun, 12 May 2013 14:59:54 -0400 (EDT) Date: Sun, 12 May 2013 14:59:54 -0400 From: Jeffrey Haas To: Glen Kent Subject: Re: few queries regarding BFD Message-ID: <20130512185954.GG12732@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 12 May 2013 19:00:00 -0000 On Mon, May 13, 2013 at 12:22:00AM +0530, Glen Kent wrote: > Authentication is never used to hide information in the routing protocols. > > Its always used to authenticate the sender of the protocol packet. Usually, > its configured only to detect misconfigured peers. This is certainly a common operational benefit from authentication - and often one that drives the lowest common denominator on protocols. But that said, it's also there to protect against active attacks on the protocol by "bad guys". How strong you protect your protocol depends on who you're trying to protect yourself against and how critical your protocol is. Given the nature of BFD, an active attack would likely either try to: - Keep the protocol up when it's really down. - Keep the protocol down when it should come up. Feel free to construct your own attack trees against the business cases of BFD deployment given the above. :-) > Since BFD is a fast > protocol and is often implemented in HW, getting authentication to work is > complex. This i believe is the primary reason why the authentication > related drafts in BFD WG have still not progressed. Minimally, better crypto eats more CPU. In some cases, you can get hardware assist on that crypto and thus not take a penalty against a more general purpose CPU that is supposed to be doing other forwarding critical things. The question that must be asked as a protocol developer or implementor is "what is the benefit and against what am I protecting my protocol". This will usually lead to the appropriate business case. -- Jeff (all, IMO) From jhaas@slice.pfrc.org Mon May 13 09:18:58 2013 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 7F3D721F940D for ; Mon, 13 May 2013 09:18:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L92yNyDaba6H for ; Mon, 13 May 2013 09:18:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 45B4C21F9408 for ; Mon, 13 May 2013 09:18:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B06DBC5B9; Mon, 13 May 2013 12:18:52 -0400 (EDT) Date: Mon, 13 May 2013 12:18:52 -0400 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Message-ID: <20130513161852.GH12732@pfrc> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> <20130510221623.GF12732@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130510221623.GF12732@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 13 May 2013 16:18:58 -0000 On Fri, May 10, 2013 at 06:16:23PM -0400, Jeffrey Haas wrote: > Also, authors, please make a positive acknowledgement to the mailing list as > to whether you are aware of any IPR against this draft. Chiming in as an author, I am not personally aware of any intellectual property restrictions on this draft. -- Jeff From jhaas@slice.pfrc.org Mon May 13 16:37:10 2013 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 9BD9321F8EA6 for ; Mon, 13 May 2013 16:37:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZnjJ3HXmMDJ for ; Mon, 13 May 2013 16:37:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5321F90BB for ; Mon, 13 May 2013 16:37:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A617EC5B9; Mon, 13 May 2013 19:37:04 -0400 (EDT) Date: Mon, 13 May 2013 19:37:04 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [amankin@verisign.com: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence] Message-ID: <20130513233704.GQ12732@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 13 May 2013 23:37:10 -0000 I've occasionally been asked as a working group chair how you can get more involved in IETF leadership. This is a good way. -- Jeff (been there, sorta still doing that) ----- Forwarded message from "Mankin, Allison" ----- Date: Mon, 13 May 2013 21:27:21 +0000 From: "Mankin, Allison" To: "ietf-announce@ietf.org" Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence The IETF nominating committee (nomcom) process for 2013-14 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF! I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the address given. ----- End forwarded message ----- From manav.bhatia@alcatel-lucent.com Mon May 13 17:04:02 2013 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 22DE221F958A for ; Mon, 13 May 2013 17:04:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kdWHfjfAGSy for ; Mon, 13 May 2013 17:03:55 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA3B21F8E9A for ; Mon, 13 May 2013 17:03:54 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r4E03r8V007442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 May 2013 19:03:53 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r4E03qan019116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 20:03:53 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 13 May 2013 20:03:52 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Tue, 14 May 2013 08:03:49 +0800 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Topic: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Index: AQHOT/Wdfzv0uWjvdUu3b6CPmJDPDpkDzQZA Date: Tue, 14 May 2013 00:03:48 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C301ECF5@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> <20130510221623.GF12732@pfrc> <20130513161852.GH12732@pfrc> In-Reply-To: <20130513161852.GH12732@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.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: Tue, 14 May 2013 00:04:02 -0000 Same here. Cheers, Manav=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, May 13, 2013 9:49 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt >=20 > On Fri, May 10, 2013 at 06:16:23PM -0400, Jeffrey Haas wrote: > > Also, authors, please make a positive acknowledgement to=20 > the mailing=20 > > list as to whether you are aware of any IPR against this draft. >=20 > Chiming in as an author, I am not personally aware of any=20 > intellectual property restrictions on this draft. >=20 > -- Jeff > = From jhaas@slice.pfrc.org Tue May 14 08:01:19 2013 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 ECB4421F8A14 for ; Tue, 14 May 2013 08:01:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+3ga4Km4JSh for ; Tue, 14 May 2013 08:01:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88121F8203 for ; Tue, 14 May 2013 08:01:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 60FA7C41C; Tue, 14 May 2013 11:00:58 -0400 (EDT) Date: Tue, 14 May 2013 11:00:58 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Not meeting in Berlin (IETF 87) Message-ID: <20130514150058.GE5406@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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: Tue, 14 May 2013 15:01:19 -0000 After discussing with my co-chair, it appears we don't have a need to meet in Berlin. Work is proceeding on the list fine and drafts are getting adequate discussion. We need to bump people to republish a few drafts, but otherwise we're good. We will be posting summary slides of WG status as part of the proceedings. -- Jeff From jhaas@slice.pfrc.org Tue May 14 14:30:12 2013 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 023DA21F8488 for ; Tue, 14 May 2013 14:30:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQsUCjuXGA4J for ; Tue, 14 May 2013 14:30:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 024FB21F90E0 for ; Tue, 14 May 2013 14:30:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6C591C5CA; Tue, 14 May 2013 17:30:06 -0400 (EDT) Date: Tue, 14 May 2013 17:30:06 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Proposed update to WG milestones Message-ID: <20130514213006.GG5406@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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: Tue, 14 May 2013 21:30:12 -0000 As everyone is doubtless aware, we're well past our proposed milestones for the WG. Our AD has prodded us to update them. Here is my proposal: November 2013 Submit the BFD MIB to the IESG to be considered as a Proposed Standard November 2013 Submit the BFD over LAG document to the IESG to be considered as a Proposed Standard June 2014 Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard January 2015 Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard January 2015 Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard January 2015 Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Motivation for the above dates: November 2013 - these documents are likely to be ready by that upcoming IETF. The MIB is mature and waiting for nits to be addressed (and I'll re-send those nits to the authors soon). The BFD over LAG work has already done some interop work and the document needs a little bit of final smithing (please review!) to get it done. June 2014 - P2MP is already partially implemented by ALU. Other vendors have suggested they have implementations in progress. I'd prefer to see at least one more implementation before we LC the document. Based on feedback from implementors, the tail reporting mechanism is not getting implemented. This may suggest the feature should be pruned from the final spec. The crypto documents have been heavily reviewed at this point. However, I've yet to hear from anyone willing to implement them to advance them in standards. The January date is basically saying "not sure when". The MIB extension will be authored in the background to support this work should it ever get implemented. -- Jeff From nobo@cisco.com Tue May 14 18:13:10 2013 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 B6BD221F86F7 for ; Tue, 14 May 2013 18:13:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJlhpfvBa40R for ; Tue, 14 May 2013 18:13:05 -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 31D6921F86CE for ; Tue, 14 May 2013 18:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1096; q=dns/txt; s=iport; t=1368580385; x=1369789985; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0vB8WOo+8F8Ln2n6I+bXrZPWrXzBjTpWW8uRkqA3xek=; b=Om28tCviKYOfkPEYaN1zhEewjy7xeI863kg0MKb0eqlIkkRal2DZ6o95 iKJ2zkNKPk0vy6xPfGBOWMzYX1I3lppr0NoXlj9d+AKzpavXQRnDhhXM/ PfO1AfIlHYyhyeYWsndW3C8o6jTtKYw8OtnM4qo4RdpUf5yNMhS8QG45N k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAIbgklGtJXG//2dsb2JhbABagmYhwGmBAhZ0giEBBDo/EgEqFEImAQQBDQ2IBAGwPox9jVyBETGCe2EDqHGDAg2BcjU X-IronPort-AV: E=Sophos;i="4.87,674,1363132800"; d="scan'208";a="207564781" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 15 May 2013 01:13:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4F1D4TQ017715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 01:13:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 14 May 2013 20:13:04 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Jeffrey Haas Subject: Reserved discriminators? Thread-Topic: Reserved discriminators? Thread-Index: Ac5RCB2RBVvL37HfRWy6cdsfP8AppQ== Date: Wed, 15 May 2013 01:13:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 15 May 2013 01:13:10 -0000 Dear BFD WG Members, [paste from redundancy thread] > Could we use discriminators ... I admit I ruled this out as we have only = zero > as a reserved value, otherwise it's up to the implementation how it assig= ns > the value and the peer just reflects the discriminator back. We could sta= rt to > define additional reserved discriminator values, e.g. 0xFFFFFFFF as the > "shadow zero" but the problem remains that a v1-only implementation may > see this discriminator value as a valid one (i.e. it's in use). [snip] Placing aside the redundancy discussion aside ... I'm curious what people think about reserving a range of discriminators of = special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF). That would certainly create more "lego pieces" for BFD, at the cost of sacr= ificing simplicity. If majority thinks this is a good idea, then we should roll out a draft res= erving them. Then people can propose ideas to (try to) grab a value from re= served range. If majority thinks this is a bad idea, well, this email will make a good ar= chive :) Regards, Nobo From jhaas@slice.pfrc.org Wed May 15 07:48:17 2013 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 249C321F8F83 for ; Wed, 15 May 2013 07:48:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjSNCTz1xFme for ; Wed, 15 May 2013 07:48:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2369D21F8F69 for ; Wed, 15 May 2013 07:48:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 87550C411; Wed, 15 May 2013 10:48:11 -0400 (EDT) Date: Wed, 15 May 2013 10:48:11 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Reserved discriminators? Message-ID: <20130515144811.GM5406@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 15 May 2013 14:48:17 -0000 On Wed, May 15, 2013 at 01:13:03AM +0000, Nobo Akiya (nobo) wrote: > Placing aside the redundancy discussion aside ... > > I'm curious what people think about reserving a range of discriminators of special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF). > > That would certainly create more "lego pieces" for BFD, at the cost of sacrificing simplicity. > > If majority thinks this is a good idea, then we should roll out a draft reserving them. Then people can propose ideas to (try to) grab a value from reserved range. > > If majority thinks this is a bad idea, well, this email will make a good archive :) One minor point opposing this is the base RFC 5880 doesn't give much idea for reserving discriminators. The recommendations are effectively to randomize them for security purposes and thus for implementations that don't understand such reserved values, we have a very small space where a PRNG could pick something in that range and confuse a speaker that is expecting this to be reserved. The usual joys of updating specs after the fact. As a final point, apparently some implementations make use of reserved ranges internally to provide for internal demultiplexing beyond "this is just a random value". Implementors with some strategies may have issue. They should obviously speak up on this thread. :-) -- Jeff From jhaas@slice.pfrc.org Wed May 15 08:08:04 2013 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 2439021F8F15 for ; Wed, 15 May 2013 08:08:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx0aZxE-oef2 for ; Wed, 15 May 2013 08:07:59 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9577921F8FE8 for ; Wed, 15 May 2013 08:07:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 533FBC1DC; Wed, 15 May 2013 11:07:57 -0400 (EDT) Date: Wed, 15 May 2013 11:07:57 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Reserved discriminators? Message-ID: <20130515150757.GN5406@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 15 May 2013 15:08:04 -0000 On Wed, May 15, 2013 at 01:13:03AM +0000, Nobo Akiya (nobo) wrote: > Placing aside the redundancy discussion aside ... > > I'm curious what people think about reserving a range of discriminators of special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF). To take this up again specifically in the context of redundancy, blanketly reserving discriminators for sessions may not work. But perhaps if your question was a bit more narrowly focused on the issue of session boot-strapping, we may have a different possibility. BFD procedure for bringing up a session from the Down state requires a Your Discriminator value of 0. For backward compatibility purposes, we cannot change that. But, if the reserved value was used *only* for the context of telling the remote side "this is your redundant connection", and some reserved value was used in Down state for Your Discriminator to help with de-multiplexing (e.g. 1 or 0xffffffff), that would be sufficient. We still have a possibility of colliding with existing sessions if the remote side makes use of the reserved value. Bumping the version number is an obvious fix but if we're going to that extent we need to think more carefully about the full work we'd want under such a rev. -- Jeff From nobo@cisco.com Wed May 15 08:54:49 2013 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 BCC0F21F880F for ; Wed, 15 May 2013 08:54:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8udQAJJ+2cDG for ; Wed, 15 May 2013 08:54:43 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 427B021F8756 for ; Wed, 15 May 2013 08:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2550; q=dns/txt; s=iport; t=1368633278; x=1369842878; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WlPIsirmTG4CUl9RcsCPzWNOH8z5O/OSyPza99JCRdc=; b=WikuKOS4Lxuts0/6G5S67LKwbz1hJJ3j6sCsphsWBoOT4JcytGuvn70q tFK5EwYjqLn0o1IYBWPOurbMUc4e3kTsVrzedrSxqT8PgVk48HXdOLXb1 foagoJsOQQ5bEp0CHCh4NCsWHhswzTuBl9aP/51RtSYkCW+TguSIqm6f1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFADivk1GtJV2c/2dsb2JhbABbgmYhwQ99FnSCHwEBAQMBOkQHBAIBCA4DBAEBCxQJBzIUCQgCBAESCId+BgG9KY5tOAaCbmEDqHGDEIIn X-IronPort-AV: E=Sophos;i="4.87,678,1363132800"; d="scan'208";a="210649117" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 15 May 2013 15:54:31 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4FFsVWC016145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 15:54:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 15 May 2013 10:54:31 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Proposed update to WG milestones Thread-Topic: Proposed update to WG milestones Thread-Index: AQHOUOpA1CA9x8EJ30SdgAhP14dq/5kGZctw Date: Wed, 15 May 2013 15:54:30 +0000 Message-ID: References: <20130514213006.GG5406@pfrc> In-Reply-To: <20130514213006.GG5406@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 15 May 2013 15:54:49 -0000 Hello Jeff, > November 2013 Submit the BFD MIB to the IESG to be considered as a > Proposed Standard I agree for BFD base MIB. For BFD MPLS MIB, it will be more beneficial to a= llow more time. Something along the line of November 2014. Regards, Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, May 14, 2013 5:30 PM > To: rtg-bfd@ietf.org > Subject: Proposed update to WG milestones >=20 > As everyone is doubtless aware, we're well past our proposed milestones > for the WG. Our AD has prodded us to update them. Here is my proposal: >=20 > November 2013 Submit the BFD MIB to the IESG to be considered as a > Proposed Standard > November 2013 Submit the BFD over LAG document to the IESG to be > considered as a Proposed Standard > June 2014 Submit the the document on BFD point-to-multipoint > support to the IESG to be considered as a Proposed Standard > January 2015 Submit the generic keying based cryptographic > authentication mechanism to the IESG to be considered as a Proposed > Standard > January 2015 Submit the cryptographic authentication procedures for BFD > to the IESG to be considered as a Proposed Standard > January 2015 Submit a BFD MIB extension in support of the generic keying > document to the IESG to be considered as a Proposed Standard >=20 > Motivation for the above dates: > November 2013 - these documents are likely to be ready by that upcoming > IETF. The MIB is mature and waiting for nits to be addressed (and I'll r= e-send > those nits to the authors soon). The BFD over LAG work has already done > some interop work and the document needs a little bit of final smithing > (please review!) to get it done. >=20 > June 2014 - P2MP is already partially implemented by ALU. Other vendors > have suggested they have implementations in progress. I'd prefer to see = at > least one more implementation before we LC the document. Based on > feedback from implementors, the tail reporting mechanism is not getting > implemented. > This may suggest the feature should be pruned from the final spec. >=20 > The crypto documents have been heavily reviewed at this point. However, > I've yet to hear from anyone willing to implement them to advance them in > standards. The January date is basically saying "not sure when". The MI= B > extension will be authored in the background to support this work should = it > ever get implemented. >=20 > -- Jeff From aldrin.ietf@gmail.com Wed May 15 09:13:23 2013 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 E429621F87FB for ; Wed, 15 May 2013 09:13:23 -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=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO7lTSgb0ZVF for ; Wed, 15 May 2013 09:13:23 -0700 (PDT) Received: from mail-gg0-x22c.google.com (mail-gg0-x22c.google.com [IPv6:2607:f8b0:4002:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 59DCF21F855A for ; Wed, 15 May 2013 09:13:23 -0700 (PDT) Received: by mail-gg0-f172.google.com with SMTP id h3so394649gge.17 for ; Wed, 15 May 2013 09:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=XjyRsIJeprC2wdFHe+t6bgVGTy5jjiN/6isEt1YzZfw=; b=LU4kOO3m8SkKZfWvneMIKmmRuw+F2lAR+zOhJBLYiMcfN4THQUnzvCU4xI03X/GgOr mNXehLFqLGNRmq1BeqZTcivtZFIsyrCmyU1RDOoyrehHVCI04dfRsxipgyXXOcS0TlI7 N1IDwHm9pMHtTjZdAq09tj3DRPtYL1woJHAbU/x1zsyxPCan48yZse0TjfJ8Du7ltEB9 9c+pVIib6Kh2IGEek1Qe3doy4Vc32Re/J8NlpnP/Q23VgOZ0YcVOHdN582i8OEBoW33d lztZRBo0d9QJnkn3aOoifrmjn0+t+c2YFhV0yC8u7pp4lv3cH2wZ/kwDBZLP0d6KC8Dr fNcQ== X-Received: by 10.236.171.41 with SMTP id q29mr5149577yhl.57.1368634402812; Wed, 15 May 2013 09:13:22 -0700 (PDT) Received: from [10.0.20.239] ([200.68.87.133]) by mx.google.com with ESMTPSA id v34sm4578550yhn.26.2013.05.15.09.13.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 09:13:22 -0700 (PDT) References: <20130514213006.GG5406@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5DF8F3A4-4E43-4B64-B755-E224B46D33A1@gmail.com> X-Mailer: iPad Mail (10B329) From: Sam Aldrin Subject: Re: Proposed update to WG milestones Date: Wed, 15 May 2013 09:13:20 -0700 To: "Nobo Akiya (nobo)" 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: Wed, 15 May 2013 16:13:24 -0000 We the authors of BFD MPLS MIB are slacking a little one getting new version= published. It is definitely on our plate to publish a new version very soon. As far as date is concerned, I think we could shoot for Nov 13 itself, but g= iven how the MIB's takes time, extending a little is more reasonable approac= h. Cheers Sam Sent from my iPad On May 15, 2013, at 8:54 AM, "Nobo Akiya (nobo)" wrote: > Hello Jeff, >=20 >> November 2013 Submit the BFD MIB to the IESG to be considered as a >> Proposed Standard >=20 > I agree for BFD base MIB. For BFD MPLS MIB, it will be more beneficial to a= llow more time. Something along the line of November 2014. >=20 > Regards, > Nobo >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Jeffrey Haas >> Sent: Tuesday, May 14, 2013 5:30 PM >> To: rtg-bfd@ietf.org >> Subject: Proposed update to WG milestones >>=20 >> As everyone is doubtless aware, we're well past our proposed milestones >> for the WG. Our AD has prodded us to update them. Here is my proposal: >>=20 >> November 2013 Submit the BFD MIB to the IESG to be considered as a >> Proposed Standard >> November 2013 Submit the BFD over LAG document to the IESG to be >> considered as a Proposed Standard >> June 2014 Submit the the document on BFD point-to-multipoint >> support to the IESG to be considered as a Proposed Standard >> January 2015 Submit the generic keying based cryptographic >> authentication mechanism to the IESG to be considered as a Proposed >> Standard >> January 2015 Submit the cryptographic authentication procedures for BFD= >> to the IESG to be considered as a Proposed Standard >> January 2015 Submit a BFD MIB extension in support of the generic keyi= ng >> document to the IESG to be considered as a Proposed Standard >>=20 >> Motivation for the above dates: >> November 2013 - these documents are likely to be ready by that upcoming >> IETF. The MIB is mature and waiting for nits to be addressed (and I'll r= e-send >> those nits to the authors soon). The BFD over LAG work has already done >> some interop work and the document needs a little bit of final smithing >> (please review!) to get it done. >>=20 >> June 2014 - P2MP is already partially implemented by ALU. Other vendors >> have suggested they have implementations in progress. I'd prefer to see a= t >> least one more implementation before we LC the document. Based on >> feedback from implementors, the tail reporting mechanism is not getting >> implemented. >> This may suggest the feature should be pruned from the final spec. >>=20 >> The crypto documents have been heavily reviewed at this point. However, >> I've yet to hear from anyone willing to implement them to advance them in= >> standards. The January date is basically saying "not sure when". The MI= B >> extension will be authored in the background to support this work should i= t >> ever get implemented. >>=20 >> -- Jeff From jhaas@slice.pfrc.org Wed May 15 10:02:41 2013 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 2746E21F958B for ; Wed, 15 May 2013 10:02:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1z1qHie7lQs for ; Wed, 15 May 2013 10:02:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8D321F93D4 for ; Wed, 15 May 2013 10:02:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6D484C3DE; Wed, 15 May 2013 13:02:35 -0400 (EDT) Date: Wed, 15 May 2013 13:02:35 -0400 From: Jeffrey Haas To: Sam Aldrin Subject: Re: Proposed update to WG milestones Message-ID: <20130515170235.GO5406@pfrc> References: <20130514213006.GG5406@pfrc> <5DF8F3A4-4E43-4B64-B755-E224B46D33A1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5DF8F3A4-4E43-4B64-B755-E224B46D33A1@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 15 May 2013 17:02:41 -0000 On Wed, May 15, 2013 at 09:13:20AM -0700, Sam Aldrin wrote: > We the authors of BFD MPLS MIB are slacking a little one getting new version published. As IETF history will readily note, I have zero room to complain about MIBs taking a while for publication. > As far as date is concerned, I think we could shoot for Nov 13 itself, but given how the MIB's takes time, extending a little is more reasonable approach. My recommendation would be to wait until there's an implementation before we move to WGLC. If you think you have an implementation that will cover the updated MIB, that may be reasonable. -- Jeff From Alexander.Vainshtein@ecitele.com Wed May 15 13:08:21 2013 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 A26FB21F84F2 for ; Wed, 15 May 2013 13:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLMaTTJTNIGR for ; Wed, 15 May 2013 13:08:15 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id B29CD21F85C7 for ; Wed, 15 May 2013 13:08:10 -0700 (PDT) Received: from [193.109.254.147:13260] by server-1.bemta-14.messagelabs.com id 49/90-06919-82BE3915; Wed, 15 May 2013 20:08:08 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1368648474!4926249!4 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13643 invoked from network); 15 May 2013 20:08:07 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 May 2013 20:08:07 -0000 X-AuditID: 93eaf2e7-b7f6d6d00000348f-64-5193eb27ddf6 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 45.01.13455.72BE3915; Wed, 15 May 2013 23:08:07 +0300 (IDT) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 15 May 2013 23:08:07 +0300 Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Wed, 15 May 2013 23:08:06 +0300 From: Alexander Vainshtein To: Jeffrey Haas , "Nobo Akiya (nobo)" Subject: RE: Reserved discriminators? Thread-Topic: Reserved discriminators? Thread-Index: Ac5RCB2RBVvL37HfRWy6cdsfP8AppQAWfWSAABFMDPo= Date: Wed, 15 May 2013 20:08:05 +0000 Message-ID: References: , <20130515144811.GM5406@pfrc> In-Reply-To: <20130515144811.GM5406@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTbUhTURju3LuPq3nrbtN2XFrj9kXZYuuD1scsisjoh0qB1R+9bqft1nY3 dm8fE6JJ+ccIMjFrWBoNG/ZFWWFZWZZRI9CwQqNPi8pJFBVEJtK5XjUhOr+ec57nPM97Du9L kfoDWhPFCxIKCpyX1SSrKhPfflhm9VXmW9uqUu0tdz6r7d8HroKVRE40+ovI6Tx4RZ1HbAmD 5Zwg+CVOQmYXEp0ONi/I7+ScIdbMuxysjTUHvJwT+ZAgOVguEECCi81ONv+zlmMZL5iR4PS7 eMHtYNdtyLXY7YuWWGxs9sxptgXLkjd6eNGMLD6O95p9SBQ5NzLjk6LLpOd4aac2ENXtru8u I8KgdEI5SKIgsxBe7IoQCp4EO15d0JSDZErPtADY03+RVDZNAA6cCw8zbQB2frmtla9oGAe8 dOalRsapzFr45vYjrSwimTiAfU9LVTJhYGbAskQ7JigsmgnfVpsU/VJ4qufmkI8KS/prXqll TDN58OSHGCljPcPDd9fjQ5okZjZ8HW8ZKhXgUn/Gzw5hkjHC5+9rh5/AwOiNdlLBabD33aBa wVPh469vhvVzYV3zN42Cs2D9yT5SydXBh8feq5RcC4w/KB/2TId3Yl2qQyA9MiYuMsYqMsYq MsaqDqgaQBrvDUjFPrfVNg85eQl50Tyn33cJKN3zsQn0105vBQwF2BTaXl2Zr1dzO8WQrxWk UwSbRu9J4KMJxX5XyMOJnsLgDi8SWwGkSDaVftKOOdrFhUpQ0D9CrcG/WUGaxjv9uE8FqXCB 1fr/DWukT4cLcvWMG/fmdoQCKDjik0FRLKQtcrwuiNxo91beK/2lCSpJLiMFlyHIGloMcD6R dyt8HFioWGNvH9CrBL+ATEZ6sBeLGFnk2SGM+ozMUAIY8QcY6CzZKgVP2KhTAocQOGS2dFgO wTM0SpnCwNq9hF7TEGtc+bXkrm5KOVptKHjWVnZG7A7rJ7Yefy5c7shcYYi8WHwiu+r0/O7H FRm79hftq/P1rJ5cZThRs6j2/np6Ch3rMB79ULKtJrdAJ/6OftJm33zZULx3O7E1lvQWNA/+ 4K+dz9QXPxgYF3B5SwybC1bdW7XpVvoGeCS0mFWJHs42hwyK3B/rPoC6HgQAAA== Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" , Ajit Ranganathan 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, 15 May 2013 20:08:21 -0000 Jeff, Nobo, Marc and all, Regarding Jeff's note that "apparently some implementations make use of rese= rved ranges internally to provide for internal demultiplexing beyond "this i= s just a random value"": I am aware of some HW-assisted BFD implementations that use the discriminato= r as the address of data block keeping the session parameters in the HW assi= st. I suspect this has a good potential for conflicting with the additional rese= rved discriminator values. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] on behalf of Jeffr= ey Haas [jhaas@pfrc.org] Sent: Wednesday, May 15, 2013 4:48 PM To: Nobo Akiya (nobo) Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org; Marc Binderberger (mbin= derb) Subject: Re: Reserved discriminators? On Wed, May 15, 2013 at 01:13:03AM +0000, Nobo Akiya (nobo) wrote: > Placing aside the redundancy discussion aside ... > > I'm curious what people think about reserving a range of discriminators of= special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF). > > That would certainly create more "lego pieces" for BFD, at the cost of sac= rificing simplicity. > > If majority thinks this is a good idea, then we should roll out a draft re= serving them. Then people can propose ideas to (try to) grab a value from re= served range. > > If majority thinks this is a bad idea, well, this email will make a good a= rchive :) One minor point opposing this is the base RFC 5880 doesn't give much idea for reserving discriminators. The recommendations are effectively to randomize them for security purposes and thus for implementations that don't understand such reserved values, we have a very small space where a PRNG could pick something in that range and confuse a speaker that is expecting this to be reserved. The usual joys of updating specs after the fact. As a final point, apparently some implementations make use of reserved ranges internally to provide for internal demultiplexing beyond "this is just a random value". Implementors with some strategies may have issue. They should obviously speak up on this thread. :-) -- Jeff 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 nobo@cisco.com Wed May 15 14:45:35 2013 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 1604911E80D2 for ; Wed, 15 May 2013 14:45:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix9c5Q6JNT+M for ; Wed, 15 May 2013 14:45:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7211E80AD for ; Wed, 15 May 2013 14:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3315; q=dns/txt; s=iport; t=1368654329; x=1369863929; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vE9cQjIU89dgqiHcWYxqNEzWX9FBO/6jqqIlBns3nSM=; b=JyIwk7etuawRacuXjgjXMCNx31YjrfiUmTY4aGd05RKX9tv9m7/ifwMS OZsfRg6Wd+lJ/jdX/Ott+ea4mb23duHDsmNJioi5CCRD/0a9VDNchgRFL YJg1QJfm1ufp7PuHs1+ESZpVGXXAif1bWwJnwbTFIsnXqMofBkLt8zDxg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAHwBlFGtJV2c/2dsb2JhbABbgmYhwRB9FnSCHwEBAQQ6PwwEAgEIEQQBAQEKFAkHMhQJCAEBBAENBQiIBAG9Do1cEIEBMQcGgm5hA6hxgxCBcjU X-IronPort-AV: E=Sophos;i="4.87,679,1363132800"; d="scan'208";a="210800278" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 15 May 2013 21:45:28 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4FLjSlU023104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 21:45:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 15 May 2013 16:45:28 -0500 From: "Nobo Akiya (nobo)" To: Alexander Vainshtein , Jeffrey Haas Subject: RE: Reserved discriminators? Thread-Topic: Reserved discriminators? Thread-Index: Ac5RCB2RBVvL37HfRWy6cdsfP8AppQAnQO2AAAssIYAACCO1EA== Date: Wed, 15 May 2013 21:45:27 +0000 Message-ID: References: , <20130515144811.GM5406@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" , Ajit Ranganathan 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, 15 May 2013 21:45:35 -0000 Hello Sasha, Many thanks for chiming. If "your discriminator" of zero(0) is special cased from mapping to data bl= ock, or maps to data block containing special instructions, then am I corre= ct to assume that additional reserves of "certain range" can also be specia= l cased with few more instructions? Regards, Nobo > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Wednesday, May 15, 2013 4:08 PM > To: Jeffrey Haas; Nobo Akiya (nobo) > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org; Marc Binderberger > (mbinderb); Ajit Ranganathan > Subject: RE: Reserved discriminators? >=20 > Jeff, Nobo, Marc and all, >=20 > Regarding Jeff's note that "apparently some implementations make use of > reserved ranges internally to provide for internal demultiplexing beyond > "this is just a random value"": >=20 > I am aware of some HW-assisted BFD implementations that use the > discriminator as the address of data block keeping the session parameters= in > the HW assist. >=20 > I suspect this has a good potential for conflicting with the additional > reserved discriminator values. >=20 > My 2c, > Sasha >=20 > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] on behalf of > Jeffrey Haas [jhaas@pfrc.org] > Sent: Wednesday, May 15, 2013 4:48 PM > To: Nobo Akiya (nobo) > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org; Marc Binderberger > (mbinderb) > Subject: Re: Reserved discriminators? >=20 > On Wed, May 15, 2013 at 01:13:03AM +0000, Nobo Akiya (nobo) wrote: > > Placing aside the redundancy discussion aside ... > > > > I'm curious what people think about reserving a range of discriminators= of > special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF). > > > > That would certainly create more "lego pieces" for BFD, at the cost of > sacrificing simplicity. > > > > If majority thinks this is a good idea, then we should roll out a draft > reserving them. Then people can propose ideas to (try to) grab a value fr= om > reserved range. > > > > If majority thinks this is a bad idea, well, this email will make a > > good archive :) >=20 > One minor point opposing this is the base RFC 5880 doesn't give much idea > for reserving discriminators. The recommendations are effectively to > randomize them for security purposes and thus for implementations that > don't understand such reserved values, we have a very small space where a > PRNG could pick something in that range and confuse a speaker that is > expecting this to be reserved. >=20 > The usual joys of updating specs after the fact. >=20 > As a final point, apparently some implementations make use of reserved > ranges internally to provide for internal demultiplexing beyond "this is = just > a random value". Implementors with some strategies may have issue. > They should obviously speak up on this thread. :-) >=20 > -- Jeff >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s by > e-mail, phone or fax, and then delete the original and all copies thereof= . From marc@sniff.de Wed May 15 15:07:42 2013 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 6D41611E80E0 for ; Wed, 15 May 2013 15:07: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Tc6LMmr82B for ; Wed, 15 May 2013 15:07:41 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3861E11E80D2 for ; Wed, 15 May 2013 15:07:41 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4BA042AA0F; Wed, 15 May 2013 22:07:38 +0000 (GMT) Subject: Re: Reserved discriminators? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Thu, 16 May 2013 00:07:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F33912A-A15A-4523-8F54-EC7B4FB70BF3@sniff.de> References: , <20130515144811.GM5406@pfrc> To: Alexander Vainshtein , "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1084) Cc: "Jeff Haas \(jhaas@juniper.net\)" , rtg-bfd@ietf.org, Ajit Ranganathan 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, 15 May 2013 22:07:42 -0000 Hello Sasha and Nobo, I know about two vendors who "route" the BFD packets inside the = distributed architecture based on the discriminator. So agree, such a reserved discriminator range needs careful = considerations and cannot be too large. Anyway, lets try, it may be useful for v2 :-) Regards, Marc On 2013-05-15, at 23:45 , Nobo Akiya (nobo) wrote: > Hello Sasha, >=20 > Many thanks for chiming. >=20 > If "your discriminator" of zero(0) is special cased from mapping to = data block, or maps to data block containing special instructions, then = am I correct to assume that additional reserves of "certain range" can = also be special cased with few more instructions? >=20 > Regards, > Nobo >=20 >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Wednesday, May 15, 2013 4:08 PM >> To: Jeffrey Haas; Nobo Akiya (nobo) >> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org; Marc = Binderberger >> (mbinderb); Ajit Ranganathan >> Subject: RE: Reserved discriminators? >>=20 >> Jeff, Nobo, Marc and all, >>=20 >> Regarding Jeff's note that "apparently some implementations make use = of >> reserved ranges internally to provide for internal demultiplexing = beyond >> "this is just a random value"": >>=20 >> I am aware of some HW-assisted BFD implementations that use the >> discriminator as the address of data block keeping the session = parameters in >> the HW assist. >>=20 >> I suspect this has a good potential for conflicting with the = additional >> reserved discriminator values. >>=20 >> My 2c, >> Sasha >>=20 >> ________________________________________ >> From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] on behalf = of >> Jeffrey Haas [jhaas@pfrc.org] >> Sent: Wednesday, May 15, 2013 4:48 PM >> To: Nobo Akiya (nobo) >> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org; Marc = Binderberger >> (mbinderb) >> Subject: Re: Reserved discriminators? >>=20 >> On Wed, May 15, 2013 at 01:13:03AM +0000, Nobo Akiya (nobo) wrote: >>> Placing aside the redundancy discussion aside ... >>>=20 >>> I'm curious what people think about reserving a range of = discriminators of >> special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF). >>>=20 >>> That would certainly create more "lego pieces" for BFD, at the cost = of >> sacrificing simplicity. >>>=20 >>> If majority thinks this is a good idea, then we should roll out a = draft >> reserving them. Then people can propose ideas to (try to) grab a = value from >> reserved range. >>>=20 >>> If majority thinks this is a bad idea, well, this email will make a >>> good archive :) >>=20 >> One minor point opposing this is the base RFC 5880 doesn't give much = idea >> for reserving discriminators. The recommendations are effectively to >> randomize them for security purposes and thus for implementations = that >> don't understand such reserved values, we have a very small space = where a >> PRNG could pick something in that range and confuse a speaker that is >> expecting this to be reserved. >>=20 >> The usual joys of updating specs after the fact. >>=20 >> As a final point, apparently some implementations make use of = reserved >> ranges internally to provide for internal demultiplexing beyond "this = is just >> a random value". Implementors with some strategies may have issue. >> They should obviously speak up on this thread. :-) >>=20 >> -- Jeff >>=20 >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If 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. >=20 From lokeshnb1@gmail.com Thu May 16 21:30:27 2013 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 DE14211E80E4 for ; Thu, 16 May 2013 21:30:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P7OE11ZPCRm for ; Thu, 16 May 2013 21:30:22 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id A8E0121F8A53 for ; Thu, 16 May 2013 21:30:22 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id o6so4663092oag.16 for ; Thu, 16 May 2013 21:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rf9Htl5OVU5YcBHPbVbRUzuHDBzeWuW7mVpiopmU2vI=; b=ULMIO+EAFCGRupiW3OML4HJRdAN1yd0QPhucJsOxyqxaP6MukLQwNWxm8fPfl4UItK iguSmSwm3vl3f7hxHb13cASL9l7OnD5LL84NO5BTl5LFdiJ2VGtnNU25/q8TR4E7z4Tx KEuqEedW2IWN6Mx8czff5R+bUU8/EOGvF2CL3KBQqlPJS9Z5THfg/CBg6LzNt42pMOfq e8LRNYWDCOVxTPOnJyUC2/W9qnWxY5U+3dK432InHbYRhCSo7vk0QGs9aC4wvKXC6lme rMDJj8/WIFSJ+Xa5g/HY3ZzP/coTzdIq8EPSuQQcU5t+zSTgmxxdjrry2z692H/7Ol00 NNvQ== MIME-Version: 1.0 X-Received: by 10.60.79.165 with SMTP id k5mr7026829oex.108.1368765022196; Thu, 16 May 2013 21:30:22 -0700 (PDT) Received: by 10.76.154.163 with HTTP; Thu, 16 May 2013 21:30:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 May 2013 10:00:22 +0530 Message-ID: Subject: Re: few queries regarding BFD From: Lokesh NB To: Marc Binderberger Content-Type: multipart/alternative; boundary=089e012281b6edde0b04dce270a4 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, 17 May 2013 04:30:28 -0000 --089e012281b6edde0b04dce270a4 Content-Type: text/plain; charset=ISO-8859-1 Thanks Marc for the answers, >> 2. what is the currently supported maximum number of BFD sessions in high end routers? is it in the orders of hundreds of thousands? >Thousands. Details may depend on the timer values when the implementation is software based, still >system-wide I stick to "thousands". do you have any information about what is the highest number of BFD sessions supported by high end routers? I mean how many thousands of sessions do they support? I searched online but could not find the info. Regards -Lokesh On Fri, May 3, 2013 at 3:30 PM, Marc Binderberger wrote: > Hello Lokesh, > > some questions are quite generic but nevertheless ... > > > > 1. How to arrive at maximum number of BFD sessions to be supported in a > high end router.? > > distributed architecture and/or using ASIC/FPGA/NP to offload the packet > Tx/Rx > > > > 2. what is the currently supported maximum number of BFD sessions in > high end routers? is it in the orders of hundreds of thousands? > > Thousands. Details may depend on the timer values when the implementation > is software based, still system-wide I stick to "thousands". > > > > 3. What is the minimum Tx time to be supported for layer 3 UDP encap > peers? I know cisco supports minimum 50 msec but can we expect requirement > for IP peers to be monitored below that 50 msecs? like 10,20 msec? > > Actually this particular vendor you mention supports 15msec for high-end > equipment today. With a multiplier of 2 that makes a detection time of > 30msec maximum, so depending on the fiber length in a network that could > make the 50-60msec time for detection & restoration. > > Obviously: the faster the timer the better :-) , for MPLS-TP OAM the usual > number you hear is 3.3msec (so 10msec detection time with a multiplier of > 3). > > > > 4. What is average Tx time usually IP peers settle for in general? is it > like 100-300 msec? In other words what is usually configured Tx time for IP > peers? > > there is no single number, too many network designs out there in real > life. In the core customers typically go fast, to the endpoints some > customers go slower, just to stay below 1sec detection time so VoIP > controller don't freak out. > > > Regards, Marc > > > > > 5. What is the expected percentage of BFD traffic of the total bandwidth > of the device? I know it depends on how many sessions are active in > parallel and Tx/Rx timers but in general is it correct to estimate that BFD > traffic generally should not exceed 2 to 5 % of the total bandwidth > available for user data? > > > > 6. How frequently Auth is used in general deployments? is it only used > for multi hop peers usually? > > > > Regards > > -Lokesh > > > > > > > > > > > > > > > --089e012281b6edde0b04dce270a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Marc for the answers,

>>= ; 2. what is the currently supported maximum number of BFD sessions=20 in high end routers? is it in the orders of hundreds of thousands?

>Thousands. Details may depend on the timer values when the=20 implementation is software based, still >system-wide I stick to=20 "thousands".

do you have any information about what = is the highest number of BFD sessions supported by high end routers? I mean= how many thousands of sessions do they support? I searched online but coul= d not find the info.

Regards
-Lokesh




On Fri, May 3, 2013 at 3:30 PM, Marc Binderberger <marc@sniff.de&g= t; wrote:
Hello Lokesh,

some questions are quite generic but nevertheless ...


> 1. How to arrive at maximum number of BFD sessions to be supported in = a high end router.?

distributed architecture and/or using ASIC/FPGA/NP to offload the packet Tx= /Rx


> 2. what is the currently supported maximum number of BFD sessions in h= igh end routers? is it in the orders of hundreds of thousands?

Thousands. Details may depend on the timer values when the implementation i= s software based, still system-wide I stick to "thousands".


> 3. What is the minimum Tx time to be supported for layer 3 UDP encap p= eers? I know cisco supports minimum 50 msec but can we expect requirement f= or IP peers to be monitored below that 50 msecs? like 10,20 msec?

Actually this particular vendor you mention supports 15msec for high-end eq= uipment today. With a multiplier of 2 that makes a detection time of 30msec= maximum, so depending on the fiber length in a network that could make the= 50-60msec time for detection & restoration.

Obviously: the faster the timer the better :-) , for MPLS-TP OAM the usual = number you hear is 3.3msec (so 10msec detection time with a multiplier of 3= ).


> 4. What is average Tx time usually IP peers settle for in general? is = it like 100-300 msec? In other words what is usually configured Tx time for= IP peers?

there is no single number, too many network designs out there in real life.= In the core customers typically go fast, to the endpoints some customers g= o slower, just to stay below 1sec detection time so VoIP controller don'= ;t freak out.


Regards, Marc



> 5. What is the expected percentage of BFD traffic of the total bandwid= th of the device? I know it depends on how many sessions are active in para= llel and Tx/Rx timers but in general is it correct to estimate that BFD tra= ffic generally should not exceed 2 to 5 % of the total bandwidth available = for user data?
>
> 6. How frequently Auth is used in general deployments? is it only used= for multi hop peers usually?
>
> Regards
> -Lokesh
>
>
>
>
>
>



--089e012281b6edde0b04dce270a4-- From marc@sniff.de Fri May 17 00:41:28 2013 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 102A021F9227 for ; Fri, 17 May 2013 00:41: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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFhdX0iUx7aZ for ; Fri, 17 May 2013 00:41:27 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9344821F92FC for ; Fri, 17 May 2013 00:41:23 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 6B5522AA0F; Fri, 17 May 2013 07:41:21 +0000 (GMT) Subject: Re: few queries regarding BFD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-19--372746984 From: Marc Binderberger In-Reply-To: Date: Fri, 17 May 2013 09:41:16 +0200 Message-Id: <4201D9DD-6751-4466-9A62-D9131B10C936@sniff.de> References: To: Lokesh NB 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, 17 May 2013 07:41:28 -0000 --Apple-Mail-19--372746984 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Lokesh, I know about systems that support 8k - 16k BFD sessions per linecard and = "no limit" per system. For software-based I/O we talk about intervals of = several hundreds of milliseconds then, hardware-based I/O can deliver = much faster though. I use quotation marks as it mainly means no hard limits in the code; in = reality one may find certain code/data structures like SNMP work fine = for a few thousands but not for hundreds of thousands of sessions - and = need optimization. Regards, Marc On 2013-05-17, at 6:30 , Lokesh NB wrote: > Thanks Marc for the answers, >=20 > >> 2. what is the currently supported maximum number of BFD sessions = in high end routers? is it in the orders of hundreds of thousands? >=20 > >Thousands. Details may depend on the timer values when the = implementation is software based, still >system-wide I stick to = "thousands". >=20 > do you have any information about what is the highest number of BFD = sessions supported by high end routers? I mean how many thousands of = sessions do they support? I searched online but could not find the info. >=20 > Regards > -Lokesh >=20 >=20 >=20 >=20 > On Fri, May 3, 2013 at 3:30 PM, Marc Binderberger = wrote: > Hello Lokesh, >=20 > some questions are quite generic but nevertheless ... >=20 >=20 > > 1. How to arrive at maximum number of BFD sessions to be supported = in a high end router.? >=20 > distributed architecture and/or using ASIC/FPGA/NP to offload the = packet Tx/Rx >=20 >=20 > > 2. what is the currently supported maximum number of BFD sessions in = high end routers? is it in the orders of hundreds of thousands? >=20 > Thousands. Details may depend on the timer values when the = implementation is software based, still system-wide I stick to = "thousands". >=20 >=20 > > 3. What is the minimum Tx time to be supported for layer 3 UDP encap = peers? I know cisco supports minimum 50 msec but can we expect = requirement for IP peers to be monitored below that 50 msecs? like 10,20 = msec? >=20 > Actually this particular vendor you mention supports 15msec for = high-end equipment today. With a multiplier of 2 that makes a detection = time of 30msec maximum, so depending on the fiber length in a network = that could make the 50-60msec time for detection & restoration. >=20 > Obviously: the faster the timer the better :-) , for MPLS-TP OAM the = usual number you hear is 3.3msec (so 10msec detection time with a = multiplier of 3). >=20 >=20 > > 4. What is average Tx time usually IP peers settle for in general? = is it like 100-300 msec? In other words what is usually configured Tx = time for IP peers? >=20 > there is no single number, too many network designs out there in real = life. In the core customers typically go fast, to the endpoints some = customers go slower, just to stay below 1sec detection time so VoIP = controller don't freak out. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > > 5. What is the expected percentage of BFD traffic of the total = bandwidth of the device? I know it depends on how many sessions are = active in parallel and Tx/Rx timers but in general is it correct to = estimate that BFD traffic generally should not exceed 2 to 5 % of the = total bandwidth available for user data? > > > > 6. How frequently Auth is used in general deployments? is it only = used for multi hop peers usually? > > > > Regards > > -Lokesh > > > > > > > > > > > > >=20 >=20 >=20 --Apple-Mail-19--372746984 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Lokesh,

I know about systems that support 8k - 16k = BFD sessions per linecard and "no limit" per system. For software-based = I/O we talk about intervals of several hundreds of milliseconds then, = hardware-based I/O can deliver much faster = though.

I use quotation marks as it mainly = means no hard limits in the code; in reality one may find certain = code/data structures like SNMP work fine for a few thousands but not for = hundreds of thousands of sessions - and need = optimization.


Regards, = Marc




= On 2013-05-17, at 6:30 , Lokesh NB wrote:

Thanks Marc for the answers,

>> = 2. what is the currently supported maximum number of BFD sessions=20 in high end routers? is it in the orders of hundreds of thousands?

>Thousands. Details may depend on the timer values when the=20 implementation is software based, still >system-wide I stick to=20 "thousands".

do you have any information about what is the = highest number of BFD sessions supported by high end routers? I mean how = many thousands of sessions do they support? I searched online but could = not find the info.
=
Regards
-Lokesh




On Fri, May 3, 2013 at 3:30 PM, Marc Binderberger = <marc@sniff.de> wrote:
Hello Lokesh,

some questions are quite generic but nevertheless ...


> 1. How to arrive at maximum number of BFD sessions to be supported = in a high end router.?

distributed architecture and/or using ASIC/FPGA/NP to offload the packet = Tx/Rx


> 2. what is the currently supported maximum number of BFD sessions = in high end routers? is it in the orders of hundreds of thousands?

Thousands. Details may depend on the timer values when the = implementation is software based, still system-wide I stick to = "thousands".


> 3. What is the minimum Tx time to be supported for layer 3 UDP = encap peers? I know cisco supports minimum 50 msec but can we expect = requirement for IP peers to be monitored below that 50 msecs? like 10,20 = msec?

Actually this particular vendor you mention supports 15msec for high-end = equipment today. With a multiplier of 2 that makes a detection time of = 30msec maximum, so depending on the fiber length in a network that could = make the 50-60msec time for detection & restoration.

Obviously: the faster the timer the better :-) , for MPLS-TP OAM the = usual number you hear is 3.3msec (so 10msec detection time with a = multiplier of 3).


> 4. What is average Tx time usually IP peers settle for in general? = is it like 100-300 msec? In other words what is usually configured Tx = time for IP peers?

there is no single number, too many network designs out there in real = life. In the core customers typically go fast, to the endpoints some = customers go slower, just to stay below 1sec detection time so VoIP = controller don't freak out.


Regards, Marc



> 5. What is the expected percentage of BFD traffic of the total = bandwidth of the device? I know it depends on how many sessions are = active in parallel and Tx/Rx timers but in general is it correct to = estimate that BFD traffic generally should not exceed 2 to 5 % of the = total bandwidth available for user data?
>
> 6. How frequently Auth is used in general deployments? is it only = used for multi hop peers usually?
>
> Regards
> -Lokesh
>
>
>
>
>
>





= --Apple-Mail-19--372746984-- From nobo@cisco.com Fri May 17 08:35:40 2013 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 177CD21F96A2 for ; Fri, 17 May 2013 08:35:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE87RNNIrtvl for ; Fri, 17 May 2013 08:35:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 36C3021F969A for ; Fri, 17 May 2013 08:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1849; q=dns/txt; s=iport; t=1368804934; x=1370014534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4e1P3wgClmgz+0OqJFKKyKrzqovovycAC4KF6+BJrfw=; b=UQPXOv21LG1SwAau8P6UFSRjezcsR4j4f6iSklCRCneRaHQtQuFbTDyU Tg/ZWNYJrCgMN5slw86KN2y90qRd6Mq/33Hj4t4jbaDdxgwd8p+SUEAMg IFoWEMH0OaNeBFmceN1wbcf2uVdZ+HleeCOk2eDY+nJRoCw7qKxdey3CH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAMBNllGtJV2b/2dsb2JhbABagmchwgB8FnSCHwEBAQMBOj8FCwIBCA4EEBQQMhcOAQEEDg2HfgYBvUGOcDEHgnNhA6h4gw+CJg X-IronPort-AV: E=Sophos;i="4.87,693,1363132800"; d="scan'208";a="211900992" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 May 2013 15:35:33 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4HFZXf6010543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 15:35:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 17 May 2013 10:35:33 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: Reserved discriminators? Thread-Topic: Reserved discriminators? Thread-Index: Ac5RCB2RBVvL37HfRWy6cdsfP8AppQAn8aeAAFeCzPA= Date: Fri, 17 May 2013 15:35:32 +0000 Message-ID: References: <20130515150757.GN5406@pfrc> In-Reply-To: <20130515150757.GN5406@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 17 May 2013 15:35:40 -0000 Hello Jeff, et al, > But, if the reserved value was used *only* for the context of telling the > remote side "this is your redundant connection", and some reserved value > was used in Down state for Your Discriminator to help with de-multiplexin= g > (e.g. > 1 or 0xffffffff), that would be sufficient. Correct, that was my thoughts. Let's say reserved value one(1) was used for= shadow session bootstrapping purpose. Value one(1) of shadow is equivalent= of value zero(0) of primary. If "your discriminator =3D=3D 1" is received = on a node which understands this, then it is to map to shadow session. De-m= ultiplex success. - Benefit of the redundancy concept is seen more on distributed systems or = a system having at least two cards (ex: 2 route processor cards) which BFD = can run actively. - Benefit of the redundancy concept is also seen more on those BFD sessions= which aren't tied to specific physical interfaces (ex: multihop, logical/v= irtual interfaces).=20 - Redundancy concept is applicable to both SW and HW based BFD. Scope of use case has limitations, in terms of system architecture as well = as BFD type, but for those that this applies to, I still do see great benef= its. > We still have a possibility of colliding with existing sessions if the re= mote > side makes use of the reserved value. Bumping the version number is an > obvious fix but if we're going to that extent we need to think more caref= ully > about the full work we'd want under such a rev. I still do not see any implementations which cannot support few more reserv= ed discriminators. But a node speaking to another which doesn't support add= ed reserved discriminator range can certainly cause undesired collision. An= d I agree that bumping the version number would solve this easily. Regards, Nobo From internet-drafts@ietf.org Fri May 17 09:08:26 2013 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 5D87B21F91B7; Fri, 17 May 2013 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dsUmjRCeoOl; Fri, 17 May 2013 09:08:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6970121F8F6E; Fri, 17 May 2013 09:08:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130517160822.32406.90260.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 09:08:22 -0700 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, 17 May 2013 16:08:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD for Multipoint Networks Author(s) : Dave Katz Dave Ward Filename : draft-ietf-bfd-multipoint-02.txt Pages : 29 Date : 2013-05-10 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg-bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-multipoint-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-ipr@ietf.org Fri May 17 09:39:30 2013 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 9479021F9724; Fri, 17 May 2013 09:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ40DCEIHO30; Fri, 17 May 2013 09:39:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B4721F919D; Fri, 17 May 2013 09:39:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: manav.bhatia@alcatel-lucent.com, mach@huawei.com, sboutros@cisco.com, mbinderb@cisco.com, jhaas@juniper.net Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 09:39:30 -0700 X-Mailman-Approved-At: Fri, 17 May 2013 10:07:36 -0700 Cc: dward@cisco.com, rtg-bfd@ietf.org, ipr-announce@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, 17 May 2013 16:39:30 -0000 Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey Haas: An IPR disclosure that pertains to your Internet-Draft entitled "Bidirecti= onal Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces" (dra= ft- ietf-bfd-on-lags) was submitted to the IETF Secretariat on 2013-05-15 and h= as been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2081/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00.""); The IETF Secretariat From jhaas@slice.pfrc.org Fri May 17 10:17:38 2013 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 0355811E80EA; Fri, 17 May 2013 10:17:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfOadPHSfoTt; Fri, 17 May 2013 10:17:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECD721F97D3; Fri, 17 May 2013 10:17:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0C9F8C3DE; Fri, 17 May 2013 13:17:32 -0400 (EDT) Date: Fri, 17 May 2013 13:17:31 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" , sboutros@cisco.com, swallow@cisco.com, nketley@cisco.com, cpignata@cisco.com, Marc Binderberger Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Message-ID: <20130517171731.GC22923@pfrc> References: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 17 May 2013 11:16:55 -0700 Cc: jhaas@juniper.net, dward@cisco.com, rtg-bfd@ietf.org, ipr-announce@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, 17 May 2013 17:17:38 -0000 On Fri, May 17, 2013 at 09:39:30AM -0700, IETF Secretariat wrote: > > Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey Haas: > > An IPR disclosure that pertains to your Internet-Draft entitled "Bidirectional > Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces" (draft- > ietf-bfd-on-lags) was submitted to the IETF Secretariat on 2013-05-15 and has > been posted on the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2081/). The title of the IPR disclosure is > "Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00.""); FYI: http://www.google.com/patents/US8111611 Sami, Marc, George, Nobo, Neil, Carlos - please acknowledge that this completes your understanding of IPR on this draft and that you're not aware of any other claims. -- Jeff From nobo@cisco.com Fri May 17 10:24:21 2013 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 C9C0A21F97B7; Fri, 17 May 2013 10:24:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv10NEL54IQR; Fri, 17 May 2013 10:24:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 82A9A21F9732; Fri, 17 May 2013 10:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1667; q=dns/txt; s=iport; t=1368811456; x=1370021056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LOzLkVDOpyU3O4KCvdcc8eOkxI3bCl2TLKhlyW5mcrE=; b=DlvckmS5YXB1MpPP+EppMp8k3AQqldRxuuNbOBdVO8lBsqZe+qmff6Ti 3s1+HoreQhpIFXtcWWjzi+d0g/DtQS9mJistXnzSaXIkb+uVd7wjyPfW8 RnrH6hHvrPxlFzUAvCoKdcXBsetgMluTedTTxflzgWIO6ui68uZF4WUAc 0=; X-IronPort-AV: E=Sophos;i="4.87,694,1363132800"; d="scan'208";a="211658855" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 17 May 2013 17:24:14 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4HHOE0S005279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 17:24:14 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 17 May 2013 12:24:13 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "Sami Boutros (sboutros)" , "George Swallow (swallow)" , "Neil Ketley -X (nketley - Ensoft Ltd at Cisco)" , "Carlos Pignataro (cpignata)" , Marc Binderberger Subject: RE: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Topic: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Index: AQHOUyJ0kZWA8u09eUqTAhi4slnrfJkJn/9w Date: Fri, 17 May 2013 17:24:12 +0000 Message-ID: References: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> <20130517171731.GC22923@pfrc> In-Reply-To: <20130517171731.GC22923@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 17 May 2013 11:16:55 -0700 Cc: "jhaas@juniper.net" , "dward@cisco.com" , "rtg-bfd@ietf.org" , "ipr-announce@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, 17 May 2013 17:24:21 -0000 Acknowledged. Below completes my understanding of IPR regarding this draft,= and I'm not aware of any other claims. Regards, Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Friday, May 17, 2013 1:18 PM > To: Nobo Akiya (nobo); Sami Boutros (sboutros); George Swallow (swallow); > Neil Ketley -X (nketley - Ensoft Ltd at Cisco); Carlos Pignataro (cpignat= a); > Marc Binderberger > Cc: manav.bhatia@alcatel-lucent.com; mach@huawei.com; > jhaas@juniper.net; Stewart Bryant (stbryant); adrian@olddog.co.uk; > dward@cisco.com; jhaas@pfrc.org; rtg-bfd@ietf.org; ipr-announce@ietf.org > Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to draft-ie= tf- > bfd-on-lags-00 >=20 > On Fri, May 17, 2013 at 09:39:30AM -0700, IETF Secretariat wrote: > > > > Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey > Haas: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > > "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group > > (LAG) Interfaces" (draft- > > ietf-bfd-on-lags) was submitted to the IETF Secretariat on 2013-05-15 > > and has been posted on the "IETF Page of Intellectual Property Rights > Disclosures" > > (https://datatracker.ietf.org/ipr/2081/). The title of the IPR > > disclosure is "Cisco's Statement of IPR Related to > > draft-ietf-bfd-on-lags-00.""); >=20 > FYI: > http://www.google.com/patents/US8111611 >=20 > Sami, Marc, George, Nobo, Neil, Carlos - please acknowledge that this > completes your understanding of IPR on this draft and that you're not awa= re > of any other claims. >=20 > -- Jeff From sboutros@cisco.com Fri May 17 10:58:02 2013 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 DD26821F9675; Fri, 17 May 2013 10:58:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8aw576BcTQc; Fri, 17 May 2013 10:57:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E77F321F9664; Fri, 17 May 2013 10:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2050; q=dns/txt; s=iport; t=1368813478; x=1370023078; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DpoK1lOEpKVyUBob0sdpzafYMs10gF9/9K4Sw3rbdgU=; b=DvTmmp5FW3vW92h/hI50JU1npMH3WSlkBeiM76UHKvWmiodoDNdOPjex uvMeOHYvXV4zZUiceJc94019Fqo1XMDNzZdHu/YnUq7MQz0RUEG4fBICG ih5DzJozrRukDH0R+n2lQbKHunCKYClv/8RP45VzNH5PhwPqOpzuySx75 s=; X-IronPort-AV: E=Sophos;i="4.87,694,1363132800"; d="scan'208";a="211860205" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 17 May 2013 17:57:57 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4HHvv63000956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 17:57:57 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.14]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 17 May 2013 12:57:56 -0500 From: "Sami Boutros (sboutros)" To: "Neil Ketley -X (nketley - Ensoft Ltd at Cisco)" Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Topic: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Index: AQHOUyJ0pRkxmo4x0Umkcgeiu4ayb5kJ9D4AgAAARwCAAAkjAA== Date: Fri, 17 May 2013 17:57:55 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F11347F86E@xmb-rcd-x08.cisco.com> References: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> <20130517171731.GC22923@pfrc> <05B75A3837231D4BAA3E356807F48A8018660208@xmb-rcd-x04.cisco.com> In-Reply-To: <05B75A3837231D4BAA3E356807F48A8018660208@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.2.128] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 17 May 2013 11:16:55 -0700 Cc: "Carlos Pignataro \(cpignata\)" , "jhaas@juniper.net" , "dward@cisco.com" , "rtg-bfd@ietf.org" , "ipr-announce@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, 17 May 2013 17:58:03 -0000 The same here, Thanks, Sami On May 17, 2013, at 10:25 AM, Neil Ketley -X (nketley - Ensoft Ltd at Cisco= ) wrote: > Likewise acknowledged. Below completes my understanding of IPR regarding= this draft, and I'm not aware of any other claims. >=20 > Cheers > Neil >=20 >> Acknowledged. Below completes my understanding of IPR regarding this >> draft, and I'm not aware of any other claims. >>=20 >> Regards, >> Nobo >>=20 >>> -----Original Message----- >>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>> Sent: Friday, May 17, 2013 1:18 PM >>> To: Nobo Akiya (nobo); Sami Boutros (sboutros); George Swallow >>> (swallow); Neil Ketley -X (nketley - Ensoft Ltd at Cisco); Carlos >>> Pignataro (cpignata); Marc Binderberger >>> Cc: manav.bhatia@alcatel-lucent.com; mach@huawei.com; >>> jhaas@juniper.net; Stewart Bryant (stbryant); adrian@olddog.co.uk; >>> dward@cisco.com; jhaas@pfrc.org; rtg-bfd@ietf.org; >>> ipr-announce@ietf.org >>> Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to >>> draft-ietf- >>> bfd-on-lags-00 >>>=20 >>> On Fri, May 17, 2013 at 09:39:30AM -0700, IETF Secretariat wrote: >>>>=20 >>>> Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, >>>> Jeffrey >>> Haas: >>>>=20 >>>> An IPR disclosure that pertains to your Internet-Draft entitled >>>> "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group >>>> (LAG) Interfaces" (draft- >>>> ietf-bfd-on-lags) was submitted to the IETF Secretariat on >>>> 2013-05-15 and has been posted on the "IETF Page of Intellectual >>>> Property Rights >>> Disclosures" >>>> (https://datatracker.ietf.org/ipr/2081/). The title of the IPR >>>> disclosure is "Cisco's Statement of IPR Related to >>>> draft-ietf-bfd-on-lags-00.""); >>>=20 >>> FYI: >>> http://www.google.com/patents/US8111611 >>>=20 >>> Sami, Marc, George, Nobo, Neil, Carlos - please acknowledge that this >>> completes your understanding of IPR on this draft and that you're not >>> aware of any other claims. >>>=20 >>> -- Jeff From cpignata@cisco.com Fri May 17 11:16:27 2013 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 51E1021F96FF; Fri, 17 May 2013 11:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br6pNEjL7LaP; Fri, 17 May 2013 11:16:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C2B6E21F96FE; Fri, 17 May 2013 11:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1216; q=dns/txt; s=iport; t=1368814581; x=1370024181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hSBPX5GLD+nhrIxRnR7j6GQGgr1t3B1QnxKvXfP1Pto=; b=Q/fUm+FzDUEMwM+yzFy8nSy/RxXZ8YHv2Cpl/BlojkXKwgOLM9Bj/ZAg O85/bFHdMjzy1EaKwdMc/7pnK+cRc1quUUuNhcyIzAJBcJnrLnBwAyyXe p6SVUj9AYWQWQhNAzg83hsEpZb7X2yxVbqkCpUK2uHQYQE2/F5oU2i3PP 8=; X-IronPort-AV: E=Sophos;i="4.87,694,1363132800"; d="scan'208";a="211864578" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 17 May 2013 18:16:21 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4HIGL9r008732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 18:16:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 17 May 2013 13:16:20 -0500 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Topic: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Index: AQHOUyJ3WqASUKa9m0qUDYHdNS6RRpkKAs6A Date: Fri, 17 May 2013 18:16:20 +0000 Message-ID: <95067C434CE250468B77282634C96ED322B5FBC5@xmb-aln-x02.cisco.com> References: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> <20130517171731.GC22923@pfrc> In-Reply-To: <20130517171731.GC22923@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <23BC54A49042BC4B97D0269883ACD41E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 17 May 2013 11:16:55 -0700 Cc: "" , "Neil Ketley -X \(nketley - Ensoft Ltd at Cisco\)" , "" , "" , "" 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, 17 May 2013 18:16:27 -0000 On May 17, 2013, at 1:17 PM, Jeffrey Haas wrote: > On Fri, May 17, 2013 at 09:39:30AM -0700, IETF Secretariat wrote: >>=20 >> Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey H= aas: >>=20 >> An IPR disclosure that pertains to your Internet-Draft entitled "Bidirec= tional >> Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces" (= draft- >> ietf-bfd-on-lags) was submitted to the IETF Secretariat on 2013-05-15 an= d has >> been posted on the "IETF Page of Intellectual Property Rights Disclosure= s" >> (https://datatracker.ietf.org/ipr/2081/). The title of the IPR disclosur= e is >> "Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00.""); >=20 > FYI: > http://www.google.com/patents/US8111611 >=20 > Sami, Marc, George, Nobo, Neil, Carlos - please acknowledge that this > completes your understanding of IPR on this draft and that you're not awa= re > of any other claims. >=20 Cisco has IPR on draft-ietf-bfd-on-lags-00 as disclosed in ID # 2081: https= ://datatracker.ietf.org/ipr/2081/ I am not aware of any IPR related to the subject matter of this draft. Thanks, -- Carlos. > -- Jeff >=20 From mbinderb@cisco.com Fri May 17 15:50:44 2013 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 C7D5F21F9629; Fri, 17 May 2013 15:50:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQsr7s2BwkzU; Fri, 17 May 2013 15:50:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DBD7C21F9620; Fri, 17 May 2013 15:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1368831040; x=1370040640; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=crS2skQ/0khrXhAX0V77WYeeAVVcRScWgGO0qUOB71w=; b=YMYO+IzrK6vbpuSjXNVHVolgKxG8kuk93obJ2/L+rnIl3CloEnn0jT8+ hdGdTSDhkoySLdWK8kheRZ3FewlJqTMRhr0e7gW3wV7krYnjQS+8Zb2ET K1V28DgF88pOmX2Xxqd8DQKl9MW9jImGoqlAGmRlhTsJNlxn3viDkmdDk 0=; X-IronPort-AV: E=Sophos;i="4.87,695,1363132800"; d="scan'208";a="154231742" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 May 2013 22:50:16 +0000 Received: from [10.146.37.135] (dhcp-10-61-106-119.cisco.com [10.61.106.119]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4HMo9Nj007256; Fri, 17 May 2013 22:50:09 GMT Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <95067C434CE250468B77282634C96ED322B5FBC5@xmb-aln-x02.cisco.com> Date: Sat, 18 May 2013 00:50:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16E64FE6-0488-4228-8CCB-9D8DB1A637A4@cisco.com> References: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> <20130517171731.GC22923@pfrc> <95067C434CE250468B77282634C96ED322B5FBC5@xmb-aln-x02.cisco.com> To: Jeffrey Haas , "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sun, 19 May 2013 08:19:52 -0700 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "Neil Ketley -X \(nketley - Ensoft Ltd at Cisco\)" , David Ward , rtg-bfd@ietf.org, ipr-announce@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, 17 May 2013 23:12:11 -0000 Hello Jeff, same here, https://datatracker.ietf.org/ipr/2081/ is my understanding of = IPR for this draft. Not aware of any other claims. Regards, Marc On 2013-05-17, at 20:16 , Carlos Pignataro (cpignata) wrote: >=20 > On May 17, 2013, at 1:17 PM, Jeffrey Haas wrote: >=20 >> On Fri, May 17, 2013 at 09:39:30AM -0700, IETF Secretariat wrote: >>>=20 >>> Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, = Jeffrey Haas: >>>=20 >>> An IPR disclosure that pertains to your Internet-Draft entitled = "Bidirectional >>> Forwarding Detection (BFD) on Link Aggregation Group (LAG) = Interfaces" (draft- >>> ietf-bfd-on-lags) was submitted to the IETF Secretariat on = 2013-05-15 and has >>> been posted on the "IETF Page of Intellectual Property Rights = Disclosures" >>> (https://datatracker.ietf.org/ipr/2081/). The title of the IPR = disclosure is >>> "Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00.""); >>=20 >> FYI: >> http://www.google.com/patents/US8111611 >>=20 >> Sami, Marc, George, Nobo, Neil, Carlos - please acknowledge that this >> completes your understanding of IPR on this draft and that you're not = aware >> of any other claims. >>=20 >=20 > Cisco has IPR on draft-ietf-bfd-on-lags-00 as disclosed in ID # 2081: = https://datatracker.ietf.org/ipr/2081/ >=20 > I am not aware of any IPR related to the subject matter of this draft. >=20 > Thanks, >=20 > -- Carlos. >=20 >=20 >> -- Jeff >>=20 >=20 From marc@sniff.de Fri May 17 16:22:27 2013 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 96CA921F944F; Fri, 17 May 2013 16:22:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrMOCscYUzwS; Fri, 17 May 2013 16:22:22 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FBA21F9433; Fri, 17 May 2013 16:22:21 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B3B312AA0F; Fri, 17 May 2013 23:22:16 +0000 (GMT) Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <16E64FE6-0488-4228-8CCB-9D8DB1A637A4@cisco.com> Date: Sat, 18 May 2013 01:22:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EF20D98-3FBE-4CF5-91D7-C12896618BCB@sniff.de> References: <20130517163930.13198.31132.idtracker@ietfa.amsl.com> <20130517171731.GC22923@pfrc> <95067C434CE250468B77282634C96ED322B5FBC5@xmb-aln-x02.cisco.com> <16E64FE6-0488-4228-8CCB-9D8DB1A637A4@cisco.com> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sun, 19 May 2013 08:19:52 -0700 Cc: "Carlos Pignataro \(cpignata\)" , "Jeff Haas \(jhaas@juniper.net\)" , "Neil Ketley -X \(nketley - Ensoft Ltd at Cisco\)" , David Ward , rtg-bfd@ietf.org, Marc Binderberger , ipr-announce@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, 17 May 2013 23:22:28 -0000 [resending from the address that is subscribed to the list] Hello Jeff, same here, https://datatracker.ietf.org/ipr/2081/ is my understanding of = IPR for this draft. Not aware of any other claims. Regards, Marc On 2013-05-17, at 20:16 , Carlos Pignataro (cpignata) wrote: >=20 > On May 17, 2013, at 1:17 PM, Jeffrey Haas wrote: >=20 >> On Fri, May 17, 2013 at 09:39:30AM -0700, IETF Secretariat wrote: >>>=20 >>> Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, = Jeffrey Haas: >>>=20 >>> An IPR disclosure that pertains to your Internet-Draft entitled = "Bidirectional >>> Forwarding Detection (BFD) on Link Aggregation Group (LAG) = Interfaces" (draft- >>> ietf-bfd-on-lags) was submitted to the IETF Secretariat on = 2013-05-15 and has >>> been posted on the "IETF Page of Intellectual Property Rights = Disclosures" >>> (https://datatracker.ietf.org/ipr/2081/). The title of the IPR = disclosure is >>> "Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00.""); >>=20 >> FYI: >> http://www.google.com/patents/US8111611 >>=20 >> Sami, Marc, George, Nobo, Neil, Carlos - please acknowledge that this >> completes your understanding of IPR on this draft and that you're not = aware >> of any other claims. >>=20 >=20 > Cisco has IPR on draft-ietf-bfd-on-lags-00 as disclosed in ID # 2081: = https://datatracker.ietf.org/ipr/2081/ >=20 > I am not aware of any IPR related to the subject matter of this draft. >=20 > Thanks, >=20 > -- Carlos. >=20 >=20 >> -- Jeff >>=20 >=20 From gregory.mirsky@ericsson.com Mon May 20 14:29:14 2013 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 8825921F9647 for ; Mon, 20 May 2013 14:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsfAdhrOtA3Z for ; Mon, 20 May 2013 14:29:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6929E21F95F3 for ; Mon, 20 May 2013 14:29:07 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-f5-519a95a24b84 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3C.80.06724.2A59A915; Mon, 20 May 2013 23:29:06 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Mon, 20 May 2013 17:29:05 -0400 From: Gregory Mirsky To: "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Topic: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Index: AQHOTcu+41wx13zJGki3ilKRtslFy5kOnrBw Date: Mon, 20 May 2013 21:29:04 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> In-Reply-To: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B49CFFDeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPlO6iqbMCDVoPmlh8/rON0YHRY8mS n0wBjFFcNimpOZllqUX6dglcGbP/7mQvOGhXcfjFddYGxkWmXYwcHBICJhLXv9p1MXICmWIS F+6tZ+ti5OIQEjjKKHFv9gtGCGc5o8T+Q53sIFVsAkYSLzb2gNkiApoSa+dsZwWxhQXMJCY+ 2sIMETeX2LH8GxOEbSTxbdl2FhCbRUBVYtP3dWD1vAK+ElefrQSrERJwkPi0/gSYzSngKDHx 3hawGkagi76fWgMWZxYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+xwphK0ssebKfBeQxZoF8iTWv EyFWCUqcnPmEZQKjyCwkk2YhVM1CUgVRoiOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQo LU4ty003MtzECIySYxJsjjsYF3yyPMQozcGiJM7brT01UEggPbEkNTs1tSC1KL6oNCe1+BAj EwenVAOj15bDOqYPVAV4dBxu1t2T0WOeaC26OWbdC00GmRZP7WrWW5r69U/vFjv58aZerdZa 1rrs8Re16kucp5fJf3uwy1ksW7Mu9ehrxWyRNeo8UWkua55xhLqzZq+9eVBy1oxov5z5pS83 O0/IYbF/KGhnfUXlqttJtd6G9gv2xx8Vbed8Hmr9+pASS3FGoqEWc1FxIgAhQyB0YAIAAA== 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, 20 May 2013 21:29:14 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B49CFFDeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., I agree with everything in the latest version of the document but inclusion= of Section 3. I think that what is discussed in the section and use of nor= mative language are outside of the scope of BFD WG charter: Provide one or more mechanisms to run BFD over Link Aggregation Group Inter= faces. Content of the section seems more suitable as Informational or BCP with app= ropriate changes in use and interpretation of RFC 2119 language. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org Sent: Friday, May 10, 2013 3:14 PM To: i-d-announce@ietf.org Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Bidirectional Forwarding Detection (BFD) on Link = Aggregation Group (LAG) Interfaces Author(s) : Manav Bhatia Mach(Guoyi) Chen Sami Boutros Marc Binderberger Jeffrey Haas Filename : draft-ietf-bfd-on-lags-00.txt Pages : 11 Date : 2013-05-10 Abstract: This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --_000_7347100B5761DC41A166AC17F22DF1121B49CFFDeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
I agree with everything in the latest version of the document but incl= usion of Section 3. I think that what is discussed in the section and use o= f normative language are outside of the scope of BFD WG charter:
Provide one or more mechanisms to run BFD over Link Aggregation Group = Interfaces.
 
Content of the section seems more suitable as Informational or BCP wit= h appropriate changes in use and interpretation of RFC 2119 language.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
Sent: Friday, May 10, 2013 3:14 PM
To: i-d-announce@ietf.org
Cc: rtg-bfd@ietf.org
Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt
 
 
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Bidirectional Forwarding Detection W= orking Group of the IETF.
 
        Title   &nbs= p;       : Bidirectional Forwarding Detection= (BFD) on Link Aggregation Group (LAG) Interfaces
        Author(s)   =     : Manav Bhatia
           &nbs= p;            &= nbsp; Mach(Guoyi) Chen
           &nbs= p;            &= nbsp; Sami Boutros
           &nbs= p;            &= nbsp; Marc Binderberger
           &nbs= p;            &= nbsp; Jeffrey Haas
        Filename   &= nbsp;    : draft-ietf-bfd-on-lags-00.txt
        Pages   &nbs= p;       : 11
        Date    = ;        : 2013-05-10
 
Abstract:
   This document proposes a mechanism to run BFD on Link Agg= regation
   Group (LAG) interfaces.  It does so by running an in= dependent
   Asynchronous mode BFD session on every LAG member link.
 
   This mechanism allows the verification of member link con= tinuity,
   either in combination with, or in absence of, LACP. = It provides a
   shorter detection time than what LACP offers.  The c= ontinuity check
   can also cover elements of layer 3 bidirectional forwardi= ng.
 
   This mechanism utilizes a well-known UDP port distinct fr= om that of
   single-hop BFD over IP.  This new UDP port removes t= he ambiguity of
   BFD over LAG packets from BFD over single-hop IP.
 
 
 
The IETF datatracker status page for this draft is:
 
There's also a htmlized version available at:
 
 
Internet-Drafts are also available by anonymous FTP at:
 
 
--_000_7347100B5761DC41A166AC17F22DF1121B49CFFDeusaamb103erics_-- From marc@sniff.de Mon May 20 15:53:57 2013 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 0A26B21F9647 for ; Mon, 20 May 2013 15:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4FoBUeH7JmD for ; Mon, 20 May 2013 15:53:42 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E228C21F9630 for ; Mon, 20 May 2013 15:53:41 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CF0492AA0F; Mon, 20 May 2013 22:53:38 +0000 (GMT) Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--58806188 From: Marc Binderberger In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> Date: Tue, 21 May 2013 00:53:37 +0200 Message-Id: References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> To: Gregory Mirsky 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, 20 May 2013 22:53:58 -0000 --Apple-Mail-2--58806188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Greg, thanks for your feedback! Hmm. It's true that section 3.2 is not necessary to get BFD on lags = flying, it is about details implementors should consider. We are = actually discussing section 3.2 and plan to simplify the text and add = explanations. Couple of days of text smithing, I hope, then we can = extend the discussion to the list. But 3.1 ... if we remove it then we run into interoperability problems: (a) first BFD, then LACP up (in other words: BFD does not depend on LACP but LACP depends on BFD) (b) first LACP, then BFD up (in other words: LACP does not depend on BFD but BFD depends on LACP) (c) LACP and BFD are mutually independent (a) and (b) are not interoperable. We had to make a choice. The = consideration from the LAG experts was to use LACP (if enabled) to = organize the LAG before starting BFD, i.e. solution (b). Sure, we could have everyone sort it out themselves that the two allowed = ways to influence the LAG (A) BFD influences the per-port MAC operational flag (B) BFD influences the load-balance algorithm are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) cannot = be combined. Instead we explicitly mentioned (B) is used, based on the = decision for (b). This is not BCP or informal, in my opinion. Regarding the language: which aspects do you think are not acceptable to = define a new standard and need to be changed?=20 Thanks & Regards, Marc On 2013-05-20, at 23:29 , Gregory Mirsky wrote: > Dear Authors, et al., > I agree with everything in the latest version of the document but = inclusion of Section 3. I think that what is discussed in the section = and use of normative language are outside of the scope of BFD WG = charter: > Provide one or more mechanisms to run BFD over Link Aggregation Group = Interfaces. > =20 > Content of the section seems more suitable as Informational or BCP = with appropriate changes in use and interpretation of RFC 2119 language. > =20 > Regards, > Greg > =20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of internet-drafts@ietf.org > Sent: Friday, May 10, 2013 3:14 PM > To: i-d-announce@ietf.org > Cc: rtg-bfd@ietf.org > Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt > =20 > =20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Bidirectional Forwarding Detection = Working Group of the IETF. > =20 > Title : Bidirectional Forwarding Detection (BFD) on = Link Aggregation Group (LAG) Interfaces > Author(s) : Manav Bhatia > Mach(Guoyi) Chen > Sami Boutros > Marc Binderberger > Jeffrey Haas > Filename : draft-ietf-bfd-on-lags-00.txt > Pages : 11 > Date : 2013-05-10 > =20 > Abstract: > This document proposes a mechanism to run BFD on Link Aggregation > Group (LAG) interfaces. It does so by running an independent > Asynchronous mode BFD session on every LAG member link. > =20 > This mechanism allows the verification of member link continuity, > either in combination with, or in absence of, LACP. It provides a > shorter detection time than what LACP offers. The continuity check > can also cover elements of layer 3 bidirectional forwarding. > =20 > This mechanism utilizes a well-known UDP port distinct from that of > single-hop BFD over IP. This new UDP port removes the ambiguity of > BFD over LAG packets from BFD over single-hop IP. > =20 > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags > =20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 > =20 > =20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =20 > =20 --Apple-Mail-2--58806188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Greg,

thanks for your = feedback!

Hmm. It's true that section 3.2 is = not necessary to get BFD on lags flying, it is about details = implementors should consider. We are actually discussing section 3.2 and = plan to simplify the text and add explanations. Couple of days of text = smithing, I hope, then we can extend the discussion to the = list.

But 3.1 ... if we remove it then we run = into interoperability problems:

(a) first BFD, = then LACP up
(in other words: BFD does not depend on LACP but = LACP depends on BFD)
(b) first LACP, then BFD up
(in = other words: LACP does not depend on BFD but BFD depends on = LACP)
(c) LACP and BFD are mutually = independent

(a) and (b) are not interoperable. = We had to make a choice. The consideration from the LAG experts was to = use LACP (if enabled) to organize the LAG before starting BFD, i.e. = solution (b).

Sure, we could have everyone sort = it out themselves that the two allowed ways to influence the = LAG

(A) BFD influences the per-port MAC = operational flag
(B) BFD influences the load-balance = algorithm

are not independent from (a)/(b)/(c) = above, e.g. (A) and (b)/(c) cannot be combined. Instead we explicitly = mentioned (B) is used, based on the decision for = (b).

This is not BCP or informal, in my = opinion.


Regarding the language: = which aspects do you think are not acceptable to define a new standard = and need to be = changed? 


Thanks & = Regards,
Marc



<= div>On 2013-05-20, at 23:29 , Gregory Mirsky wrote:

Dear = Authors, et al.,
I agree with everything in the latest version = of the document but inclusion of Section 3. I think that what is = discussed in the section and use of normative language are outside of = the scope of BFD WG charter:
Provide one or more mechanisms to = run BFD over Link Aggregation Group = Interfaces.
 
Content of the section seems more = suitable as Informational or BCP with appropriate changes in use and = interpretation of RFC 2119 = language.
 
      &= nbsp; = Regards,
         &= nbsp;      = Greg
 
-----Original = Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of internet-drafts@ietf.org
Sent: Friday, May 10, 2013 3:14 PM
Subject: = I-D Action: = draft-ietf-bfd-on-lags-00.txt
 
 
= A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Bidirectional = Forwarding Detection Working Group of the = IETF.
 
       = ; Title           : = Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) = Interfaces
        = Author(s)       : Manav = Bhatia
         &nb= sp;            = ;    Mach(Guoyi) = Chen
          = ;            &= nbsp;   Sami = Boutros
         &n= bsp;           &nbs= p;    Marc = Binderberger
        &nb= sp;            = ;     Jeffrey = Haas
        = Filename        : = draft-ietf-bfd-on-lags-00.txt
     &nbs= p;  = Pages           : = 11
        = Date            : = 2013-05-10
 
Abstract:
   = This document proposes a mechanism to run BFD on Link = Aggregation
   Group (LAG) interfaces.  It does = so by running an independent
   Asynchronous mode = BFD session on every LAG member = link.
 
   This mechanism allows the = verification of member link continuity,
   either in = combination with, or in absence of, LACP.  It provides = a
   shorter detection time than what LACP = offers.  The continuity check
   can also cover = elements of layer 3 bidirectional = forwarding.
 
   This mechanism = utilizes a well-known UDP port distinct from that = of
   single-hop BFD over IP.  This new UDP = port removes the ambiguity of
   BFD over LAG = packets from BFD over single-hop = IP.
 
 
 
The = IETF datatracker status page for this draft is:
 
There's also a htmlized = version available at:
 
 
Internet-Drafts = are also available by anonymous FTP at:
=
 
 
=


= --Apple-Mail-2--58806188-- From gregory.mirsky@ericsson.com Tue May 21 12:05:07 2013 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 1FADA21F92C5 for ; Tue, 21 May 2013 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkK96yaOcYVJ for ; Tue, 21 May 2013 12:05:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81F8211E80A5 for ; Tue, 21 May 2013 12:04:58 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-74-519bc5592e0e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EF.FA.17121.955CB915; Tue, 21 May 2013 21:04:58 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 21 May 2013 15:04:43 -0400 From: Gregory Mirsky To: Marc Binderberger Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Topic: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Index: AQHOTcu+41wx13zJGki3ilKRtslFy5kOnrBwgABigID//9hX0A== Date: Tue, 21 May 2013 19:04:42 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B49D4B5eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPiG7U0dmBBp83c1jMvvKf2eLzn22M DkweS5b8ZPJoXd3NEsAUxWWTkpqTWZZapG+XwJXxfnFlwa8mxorde+8yNjAuL+hi5OCQEDCR uD0rtYuRE8gUk7hwbz1bFyMXh5DAUUaJvv3vmCCc5YwSjdtfMoFUsQkYSbzY2MMOYosIqErc fX2IEcRmFtCUaDrxGSwuLGAmMfHRFmaIGnOJHcu/MUHYThJvvj8Bi7MA9d462QdWzyvgK3Fr 705GiGXbGCXuzf8EVsQpYCPR37IMrJkR6Lzvp9YwQSwTl7j1ZD4TxNkCEkv2nGeGsEUlXj7+ xwphK0ssebKfBeRLZoF8iW+NgRC7BCVOznzCMoFRdBaSSbMQqmYhqYIo0ZFYsPsTG4StLbFs 4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGWxiBMbUMQk23R2Me15aHmKU5mBREudt1Z4aKCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoFRf3NJ86k5i+/tncI288mVzZ9v1C5O3Hz++Yp15dYb tqiECf2zf+5oFKScZOv1657ybwudoxVJu47vlKw6nem4+OdWWyPLfmMXoVf957qENhVc/fbv UeHXm7N2LOw9rLdY6tQ1r+yXaa84fh/aG2XfyzHDY2Fzd0XCzP9cMvP77n6SNxX2/3jvuhJL cUaioRZzUXEiALkzOVF3AgAA 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: Tue, 21 May 2013 19:05:07 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B49D4B5eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, thank you for most expedient response. Please find my notes in-lined and ta= gged with GIM>>, Regards, Greg ________________________________ From: Marc Binderberger [mailto:marc@sniff.de] Sent: Monday, May 20, 2013 3:54 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Hello Greg, thanks for your feedback! Hmm. It's true that section 3.2 is not necessary to get BFD on lags flying,= it is about details implementors should consider. We are actually discussi= ng section 3.2 and plan to simplify the text and add explanations. Couple o= f days of text smithing, I hope, then we can extend the discussion to the l= ist. GIM>> Absolutely. But 3.1 ... if we remove it then we run into interoperability problems: (a) first BFD, then LACP up (in other words: BFD does not depend on LACP but LACP depends on BFD) (b) first LACP, then BFD up (in other words: LACP does not depend on BFD but BFD depends on LACP) (c) LACP and BFD are mutually independent (a) and (b) are not interoperable. We had to make a choice. The considerati= on from the LAG experts was to use LACP (if enabled) to organize the LAG be= fore starting BFD, i.e. solution (b). GIM>> You're concerned with LAG interoperability, not interoperability of m= icro-BFD as fully addressed without Section 3. Integration of micro-BFD and= LACP is implementation issue. Interoperability or lack of thereof is resul= t of particular implementation desicions. Sure, we could have everyone sort it out themselves that the two allowed wa= ys to influence the LAG (A) BFD influences the per-port MAC operational flag (B) BFD influences the load-balance algorithm are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) cannot be = combined. Instead we explicitly mentioned (B) is used, based on the decisio= n for (b). GIM>> I think that IETF document can stop at mapping BFD state machine to A= ctor Port states of IEEE 802.1AX. This is not BCP or informal, in my opinion. Regarding the language: which aspects do you think are not acceptable to de= fine a new standard and need to be changed? GIM>> No MUST or SHOULD in Section 3. Thanks & Regards, Marc On 2013-05-20, at 23:29 , Gregory Mirsky wrote: Dear Authors, et al., I agree with everything in the latest version of the document but inclusion= of Section 3. I think that what is discussed in the section and use of nor= mative language are outside of the scope of BFD WG charter: Provide one or more mechanisms to run BFD over Link Aggregation Group Inter= faces. Content of the section seems more suitable as Informational or BCP with app= ropriate changes in use and interpretation of RFC 2119 language. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, May 10, 2013 3:14 PM To: i-d-announce@ietf.org Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Working= Group of the IETF. Title : Bidirectional Forwarding Detection (BFD) on Link = Aggregation Group (LAG) Interfaces Author(s) : Manav Bhatia Mach(Guoyi) Chen Sami Boutros Marc Binderberger Jeffrey Haas Filename : draft-ietf-bfd-on-lags-00.txt Pages : 11 Date : 2013-05-10 Abstract: This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --_000_7347100B5761DC41A166AC17F22DF1121B49D4B5eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Marc,
thank you for most expedient resp= onse. Please find my notes in-lined and tagged with GIM>>,
 
 &n= bsp;  Regards,
 &n= bsp;      Greg

From: Marc Binderberger [mailto:mar= c@sniff.de]
Sent: Monday, May 20, 2013 3:54 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org
Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt

Hello Greg,

thanks for your feedback!

Hmm. It's true that section 3.2 is not necessary to get BFD on lags fl= ying, it is about details implementors should consider. We are actually dis= cussing section 3.2 and plan to simplify the text and add explanations. Cou= ple of days of text smithing, I hope, then we can extend the discussion to the list.
 =   =
 GIM>> Absolutely.
 
But 3.1 ... if we remove it then we run into interoperability problems= :

(a) first BFD, then LACP up
(in other words: BFD does not depend on LACP but LACP depends on BFD)<= /div>
(b) first LACP, then BFD up
(in other words: LACP does not depend on BFD but BFD depends on LACP)<= /div>
(c) LACP and BFD are mutually independent

(a) and (b) are not interoperable. We had to make a choice. The consid= eration from the LAG experts was to use LACP (if enabled) to organize the L= AG before starting BFD, i.e. solution (b).
 
GIM>> You're concerned with LAG interoperability, not = interoperability of micro-BFD as fully addressed without Section 3. Integra= tion of micro-BFD and LACP is implementation issue. Interoperability or lack of thereof is result of particular impl= ementation desicions.
Sure, we could have everyone sort it out themselves that the two allow= ed ways to influence the LAG

(A) BFD influences the per-port MAC operational flag
(B) BFD influences the load-balance algorithm

are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) canno= t be combined. Instead we explicitly mentioned (B) is used, based on the de= cision for (b).
 
GIM>> I think that IETF document can stop at mapping B= FD state machine to Actor Port states of IEEE 802.1AX.

This is not BCP or informal, in my opinion.


Regarding the language: which aspects do you think are not acceptable = to define a new standard and need to be changed? 
 
GIM>> No MUST or SHOULD in Section 3.


Thanks & Regards,
Marc



On 2013-05-20, at 23:29 , Gregory Mirsky wrote:

Dear Authors, et al.,
I agree with everything in the latest version of the document but incl= usion of Section 3. I think that what is discussed in the section and use o= f normative language are outside of the scope of BFD WG charter:
Provide one or more mechanisms to run BFD over Link Aggregation Group = Interfaces.
 
Content of the section seems more suitable as Informational or BCP wit= h appropriate changes in use and interpretation of RFC 2119 language.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
Sent: Friday, May 10, 2013 3:14 PM
Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt
 
 
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Bidirectional Forwarding Detection Wo= rking Group of the IETF.
 
        Title   &nbs= p;       : Bidirectional Forwarding Detection= (BFD) on Link Aggregation Group (LAG) Interfaces
        Author(s)   =     : Manav Bhatia
           &nbs= p;            &= nbsp; Mach(Guoyi) Chen
           &nbs= p;            &= nbsp; Sami Boutros
           &nbs= p;            &= nbsp; Marc Binderberger
           &nbs= p;            &= nbsp; Jeffrey Haas
        Filename   &= nbsp;    : draft-ietf-bfd-on-lags-00.txt
        Pages   &nbs= p;       : 11
        Date    = ;        : 2013-05-10
 
Abstract:
   This document proposes a mechanism to run BFD on Link Agg= regation
   Group (LAG) interfaces.  It does so by running an in= dependent
   Asynchronous mode BFD session on every LAG member link.
 
   This mechanism allows the verification of member link con= tinuity,
   either in combination with, or in absence of, LACP. = It provides a
   shorter detection time than what LACP offers.  The c= ontinuity check
   can also cover elements of layer 3 bidirectional forwardi= ng.
 
   This mechanism utilizes a well-known UDP port distinct fr= om that of
   single-hop BFD over IP.  This new UDP port removes t= he ambiguity of
   BFD over LAG packets from BFD over single-hop IP.
 
 
 
The IETF datatracker status page for this draft is:
 
There's also a htmlized version available at:
 
 
Internet-Drafts are also available by anonymous FTP at:
 
 


--_000_7347100B5761DC41A166AC17F22DF1121B49D4B5eusaamb103erics_-- From ietf-ipr@ietf.org Tue May 21 12:37:03 2013 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 A18EE11E8108; Tue, 21 May 2013 12:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvQoHZzhgeKM; Tue, 21 May 2013 12:37:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DEE11E80FD; Tue, 21 May 2013 12:37:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: manav.bhatia@alcatel-lucent.com, mach@huawei.com, sboutros@cisco.com, mbinderb@cisco.com, jhaas@juniper.net Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521193703.18898.60714.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 12:37:03 -0700 X-Mailman-Approved-At: Wed, 22 May 2013 10:10:39 -0700 Cc: dward@cisco.com, rtg-bfd@ietf.org, ipr-announce@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: Tue, 21 May 2013 19:37:03 -0000 Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey Haas: An IPR disclosure that pertains to your Internet-Draft entitled "Bidirecti= onal Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces" (dra= ft- ietf-bfd-on-lags) was submitted to the IETF Secretariat on 2013-05-15 and h= as been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2084/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00.""); The IETF Secretariat From jhaas@slice.pfrc.org Wed May 22 10:59:37 2013 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 D68AC11E810E for ; Wed, 22 May 2013 10:59:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovN3zWdX3sIg for ; Wed, 22 May 2013 10:59:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6966F11E810A for ; Wed, 22 May 2013 10:59:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id ECC01C3E0; Wed, 22 May 2013 13:59:30 -0400 (EDT) Date: Wed, 22 May 2013 13:59:30 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Message-ID: <20130522175930.GF10807@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 22 May 2013 17:59:37 -0000 On Tue, May 21, 2013 at 07:04:42PM +0000, Gregory Mirsky wrote: > GIM>> You're concerned with LAG interoperability, not interoperability of micro-BFD as fully addressed without Section 3. Integration of micro-BFD and LACP is implementation issue. Interoperability or lack of thereof is result of particular implementation desicions. > Sure, we could have everyone sort it out themselves that the two allowed ways to influence the LAG Operation of micro-BFD sessions with LAGs with LACP present is a task we are required to resolve. IEEE will have some nasty words for us if that is not the case. > (A) BFD influences the per-port MAC operational flag We had previously decided to not do this since it put us a bit too deep into state machines in other mechanisms. Working in this space also gathered the most concern from IEEE. As you'd point out, the mac operational flag was also their recommended mechanism to avoid meddling with LACP directly. > (B) BFD influences the load-balance algorithm This was our chosen path forward. One point that pushed the authors in this direction were a multitude of implementation specific issues wherein taking the link out of service (a above) rather than simply updating the forwarding behavior made things difficult. Rather than walk the line of the protocol purists to cover a, b permitted the greatest opportunity for interoperability. > Regarding the language: which aspects do you think are not acceptable to define a new standard and need to be changed? > > GIM>> No MUST or SHOULD in Section 3. The authors have some new text in that section in review and will be desiring comments on it. -- Jeff From marc@sniff.de Thu May 23 16:44:51 2013 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 CDC8B21F8952 for ; Thu, 23 May 2013 16:44:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khEMIPuC+yNa for ; Thu, 23 May 2013 16:44:51 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04921F88BF for ; Thu, 23 May 2013 16:44:50 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id C7C282AA0F; Thu, 23 May 2013 23:44:47 +0000 (GMT) Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> Date: Fri, 24 May 2013 01:44:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37AE8E87-5955-4167-A41A-3D8643B89EF7@sniff.de> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> To: Gregory Mirsky 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: Thu, 23 May 2013 23:44:51 -0000 Hello Gregory, thanks for your comments! > GIM>> You're concerned with LAG interoperability, not interoperability = of micro-BFD as fully addressed without Section 3. Integration of = micro-BFD and LACP is implementation issue. Interoperability or lack of = thereof is result of particular implementation desicions. I understand your point of view but the draft is explicitly about BFD = for LAG Interfaces. A statement how BFD and LACP are supposed to = interact should be part of a normative specification, especially as the = lack thereof may cause interop problems. > GIM>> No MUST or SHOULD in Section 3. you mean MAY or really MUST ? I see that section 3.2 is not necessary to get BFD on LAG working. On = the other hand having one document describing the protocol work and some = corner cases for implementor seems reasonable. What about moving 3.2 = into an appendix "Notes for implementors" ? First paragraph of 3.1 is not more than some context - we could remove = it? Paragraph 2 describes the dependency between LACP and BFD. Paragraph = 3, 4 and 5 describe how actually the influence on the LAG load balance = function happens. Best regards, Marc On 2013-05-21, at 21:04 , Gregory Mirsky wrote: > Hi Marc, > thank you for most expedient response. Please find my notes in-lined = and tagged with GIM>>, > =20 > Regards, > Greg >=20 > From: Marc Binderberger [mailto:marc@sniff.de]=20 > Sent: Monday, May 20, 2013 3:54 PM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt >=20 > Hello Greg, >=20 > thanks for your feedback! >=20 > Hmm. It's true that section 3.2 is not necessary to get BFD on lags = flying, it is about details implementors should consider. We are = actually discussing section 3.2 and plan to simplify the text and add = explanations. Couple of days of text smithing, I hope, then we can = extend the discussion to the list. > =20 > GIM>> Absolutely. > =20 > But 3.1 ... if we remove it then we run into interoperability = problems: >=20 > (a) first BFD, then LACP up > (in other words: BFD does not depend on LACP but LACP depends on BFD) > (b) first LACP, then BFD up > (in other words: LACP does not depend on BFD but BFD depends on LACP) > (c) LACP and BFD are mutually independent >=20 > (a) and (b) are not interoperable. We had to make a choice. The = consideration from the LAG experts was to use LACP (if enabled) to = organize the LAG before starting BFD, i.e. solution (b). > =20 > GIM>> You're concerned with LAG interoperability, not interoperability = of micro-BFD as fully addressed without Section 3. Integration of = micro-BFD and LACP is implementation issue. Interoperability or lack of = thereof is result of particular implementation desicions. > Sure, we could have everyone sort it out themselves that the two = allowed ways to influence the LAG >=20 > (A) BFD influences the per-port MAC operational flag > (B) BFD influences the load-balance algorithm >=20 > are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) = cannot be combined. Instead we explicitly mentioned (B) is used, based = on the decision for (b). > =20 > GIM>> I think that IETF document can stop at mapping BFD state machine = to Actor Port states of IEEE 802.1AX. >=20 > This is not BCP or informal, in my opinion. >=20 >=20 > Regarding the language: which aspects do you think are not acceptable = to define a new standard and need to be changed?=20 > =20 > GIM>> No MUST or SHOULD in Section 3. >=20 >=20 > Thanks & Regards, > Marc >=20 >=20 >=20 > On 2013-05-20, at 23:29 , Gregory Mirsky wrote: >=20 >> Dear Authors, et al., >> I agree with everything in the latest version of the document but = inclusion of Section 3. I think that what is discussed in the section = and use of normative language are outside of the scope of BFD WG = charter: >> Provide one or more mechanisms to run BFD over Link Aggregation Group = Interfaces. >> =20 >> Content of the section seems more suitable as Informational or BCP = with appropriate changes in use and interpretation of RFC 2119 language. >> =20 >> Regards, >> Greg >> =20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of internet-drafts@ietf.org >> Sent: Friday, May 10, 2013 3:14 PM >> To: i-d-announce@ietf.org >> Cc: rtg-bfd@ietf.org >> Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt >> =20 >> =20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Bidirectional Forwarding Detection = Working Group of the IETF. >> =20 >> Title : Bidirectional Forwarding Detection (BFD) on = Link Aggregation Group (LAG) Interfaces >> Author(s) : Manav Bhatia >> Mach(Guoyi) Chen >> Sami Boutros >> Marc Binderberger >> Jeffrey Haas >> Filename : draft-ietf-bfd-on-lags-00.txt >> Pages : 11 >> Date : 2013-05-10 >> =20 >> Abstract: >> This document proposes a mechanism to run BFD on Link Aggregation >> Group (LAG) interfaces. It does so by running an independent >> Asynchronous mode BFD session on every LAG member link. >> =20 >> This mechanism allows the verification of member link continuity, >> either in combination with, or in absence of, LACP. It provides a >> shorter detection time than what LACP offers. The continuity = check >> can also cover elements of layer 3 bidirectional forwarding. >> =20 >> This mechanism utilizes a well-known UDP port distinct from that = of >> single-hop BFD over IP. This new UDP port removes the ambiguity = of >> BFD over LAG packets from BFD over single-hop IP. >> =20 >> =20 >> =20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags >> =20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 >> =20 >> =20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> =20 >> =20 >=20 >=20 From marc@sniff.de Sun May 26 06:18:51 2013 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 9AD5F21F8FED for ; Sun, 26 May 2013 06:18:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-yDMszoTrt8 for ; Sun, 26 May 2013 06:18:50 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AEA21F8FA5 for ; Sun, 26 May 2013 06:18:50 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id C58062AA0F; Sun, 26 May 2013 13:18:47 +0000 (GMT) Subject: The "version" topic (was: Reserved discriminators?) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Sun, 26 May 2013 15:18:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> References: <20130515150757.GN5406@pfrc> To: Jeffrey Haas , "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1084) Cc: "Jeff Haas \(jhaas@juniper.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: Sun, 26 May 2013 13:18:51 -0000 Hello everyone, sorry for me delayed response. Taking a step back. If we would write RFC5880 today then we probably = would have reserved a small number of discriminators, e.g. the first 8 = or 16 values. But RFC5880 is since 3 years out, the underlying draft is = even much older. The statement in the Spec is effectively: dear = implementor, beside the zero value do what you like with this value. We = cannot claim back parts of the number space without risking problems. This is why I tend more and more to have clean separation, be it a new = IP/UDP port like BFD-on-lags or be it a new version number. The latter = faces, I think, largely a psychological problem :-) Independent if Nobo and me can convince this audience about the = redundancy concept we propose - working on it - I do see more (private) = ideas that cover BFD sessions in a general sense, i.e. cover the various = RFCs, single-, multi-hop, with/withou label and so on. In all cases I = see people spending time to "fiddle about the bits" of the BFD v1 and = the IP header. Smart stuff but somehow crazy how wicked the new = definitions become, not to mention the difficulties for implementations = and for interop. Yes, we have a limited number of versions available. Let me throw this = idea at the BFD audience: the base v2 header would look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0| Subtype | TBD, depending on Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | The subtype (the former Diag field) would allow for 32 new definitions. = Actually I do not hope myself we define so many variations ;-) but it = opens up room that we do not have with the version field alone. To emphasize: defining a v2 header does not mean v1 is obsolete. BFD v1 = works great, I'm not trying to replace it and whenever it can be used it = must be used. For the other fields above, just quickly my thoughts (if we want to dive = deeper into this I better write a draft to discuss): - length field remains in it's position, for ease of implementation - of course I keep the discriminator concept - or it wouldn't be BFD = anymore ;-) and I keep them again at the same position (the coders of = NP, FPGA etc never have enough cycles or gates. And these fields are = used "in hardware") - not obvious here but I would define a relatively strict upper size = limit. I'm not proposing a generic TLV format, based on the difficulties = I know about implementing really fast I/O it is better to have fixed = formats, IMHO. Feedback is very welcome. And yes, I have mixed emotions myself to let = the genie out of the bottle :-) Thanks & Regards, Marc On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: > Hello Jeff, et al, >=20 >> But, if the reserved value was used *only* for the context of telling = the >> remote side "this is your redundant connection", and some reserved = value >> was used in Down state for Your Discriminator to help with = de-multiplexing >> (e.g. >> 1 or 0xffffffff), that would be sufficient. >=20 > Correct, that was my thoughts. Let's say reserved value one(1) was = used for shadow session bootstrapping purpose. Value one(1) of shadow is = equivalent of value zero(0) of primary. If "your discriminator =3D=3D 1" = is received on a node which understands this, then it is to map to = shadow session. De-multiplex success. >=20 > - Benefit of the redundancy concept is seen more on distributed = systems or a system having at least two cards (ex: 2 route processor = cards) which BFD can run actively. > - Benefit of the redundancy concept is also seen more on those BFD = sessions which aren't tied to specific physical interfaces (ex: = multihop, logical/virtual interfaces).=20 > - Redundancy concept is applicable to both SW and HW based BFD. >=20 > Scope of use case has limitations, in terms of system architecture as = well as BFD type, but for those that this applies to, I still do see = great benefits. >=20 >> We still have a possibility of colliding with existing sessions if = the remote >> side makes use of the reserved value. Bumping the version number is = an >> obvious fix but if we're going to that extent we need to think more = carefully >> about the full work we'd want under such a rev. >=20 > I still do not see any implementations which cannot support few more = reserved discriminators. But a node speaking to another which doesn't = support added reserved discriminator range can certainly cause undesired = collision. And I agree that bumping the version number would solve this = easily. >=20 > Regards, > Nobo >=20 From manav.bhatia@alcatel-lucent.com Sun May 26 21:37:38 2013 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 6A98A21F92EB for ; Sun, 26 May 2013 21:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug-tBC17mPu2 for ; Sun, 26 May 2013 21:37:31 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A4EBF21F924A for ; Sun, 26 May 2013 21:37:30 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r4R4bST0014422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 26 May 2013 23:37:28 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r4R4bQNv019506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 00:37:26 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 27 May 2013 00:37:26 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Mon, 27 May 2013 12:37:22 +0800 From: "Bhatia, Manav (Manav)" To: Marc Binderberger , Jeffrey Haas , "Nobo Akiya (nobo)" Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWhOVWNAQjdgdjUGntjfJd/sEA5kYbcQA Date: Mon, 27 May 2013 04:37:22 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> In-Reply-To: <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 04:37:38 -0000 Hi Marc, We usually do a version change when there is a very very substantial upgrad= e to the protocol - a kind that's usually non backward compatible. If we really want to introduce newer fields to the packet while being backw= ard compatible then the best approach imo is this: You stuff whatever additional information you want in a special BFD data bl= ock immediately at the end of the BFD packet. Don't include the length of t= his additional BFD block in the BFD header. Instead, account for this in th= e IPv4/IPv6 header length. +---------------------+ -- =20 | IP Header | ^ =20 | Length =3D HL+X+Y | | Header Length=20 | | v =20 +---------------------+ -- =20 | BFD Header | ^ =20 | Length =3D X | | =20 |.....................| | X =20 | | | =20 | BFD Data | =20 | | v =20 +---------------------+ -- =20 | | ^ | BFD Data Block | Y | | v +---------------------+ -- How this additional BFD data block will be used is beyond the scope of the = discussion right now. You could define that to be TLV encoded for ensuring = easy extensibility. Implementations can either implicitly figure out the presence of the BFD da= ta block by looking at the packet lengths in the headers or can explicitly = be indicated in the BFD header. If people think it's a worthwhile idea to pursue then this can be quickly d= rafted. Cheers, Manav > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger > Sent: Sunday, May 26, 2013 6:49 PM > To: Jeffrey Haas; Nobo Akiya (nobo) > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > Subject: The "version" topic (was: Reserved discriminators?) >=20 > Hello everyone, >=20 > sorry for me delayed response. >=20 > Taking a step back. If we would write RFC5880 today then we=20 > probably would have reserved a small number of=20 > discriminators, e.g. the first 8 or 16 values. But RFC5880=20 > is since 3 years out, the underlying draft is even much=20 > older. The statement in the Spec is effectively: dear=20 > implementor, beside the zero value do what you like with this=20 > value. We cannot claim back parts of the number space=20 > without risking problems. >=20 > This is why I tend more and more to have clean separation, be=20 > it a new IP/UDP port like BFD-on-lags or be it a new version=20 > number. The latter faces, I think, largely a psychological problem :-) >=20 > Independent if Nobo and me can convince this audience about=20 > the redundancy concept we propose - working on it - I do see=20 > more (private) ideas that cover BFD sessions in a general=20 > sense, i.e. cover the various RFCs, single-, multi-hop,=20 > with/withou label and so on. In all cases I see people=20 > spending time to "fiddle about the bits" of the BFD v1 and=20 > the IP header. Smart stuff but somehow crazy how wicked the=20 > new definitions become, not to mention the difficulties for=20 > implementations and for interop. >=20 >=20 > Yes, we have a limited number of versions available. Let me=20 > throw this idea at the BFD audience: the base v2 header would=20 > look like this: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 1 0| Subtype | TBD, depending on Subtype | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Your Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | >=20 >=20 > The subtype (the former Diag field) would allow for 32 new=20 > definitions. Actually I do not hope myself we define so many=20 > variations ;-) but it opens up room that we do not have with=20 > the version field alone. >=20 > To emphasize: defining a v2 header does not mean v1 is=20 > obsolete. BFD v1 works great, I'm not trying to replace it=20 > and whenever it can be used it must be used. >=20 > For the other fields above, just quickly my thoughts (if we=20 > want to dive deeper into this I better write a draft to discuss): >=20 > - length field remains in it's position, for ease of implementation >=20 > - of course I keep the discriminator concept - or it wouldn't=20 > be BFD anymore ;-) and I keep them again at the same position=20 > (the coders of NP, FPGA etc never have enough cycles or=20 > gates. And these fields are used "in hardware") >=20 > - not obvious here but I would define a relatively strict=20 > upper size limit. I'm not proposing a generic TLV format,=20 > based on the difficulties I know about implementing really=20 > fast I/O it is better to have fixed formats, IMHO. >=20 >=20 > Feedback is very welcome. And yes, I have mixed emotions=20 > myself to let the genie out of the bottle :-) >=20 >=20 > Thanks & Regards, > Marc >=20 >=20 >=20 > On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: >=20 > > Hello Jeff, et al, > >=20 > >> But, if the reserved value was used *only* for the context=20 > of telling=20 > >> the remote side "this is your redundant connection", and some=20 > >> reserved value was used in Down state for Your=20 > Discriminator to help=20 > >> with de-multiplexing (e.g. > >> 1 or 0xffffffff), that would be sufficient. > >=20 > > Correct, that was my thoughts. Let's say reserved value=20 > one(1) was used for shadow session bootstrapping purpose.=20 > Value one(1) of shadow is equivalent of value zero(0) of=20 > primary. If "your discriminator =3D=3D 1" is received on a node=20 > which understands this, then it is to map to shadow session.=20 > De-multiplex success. > >=20 > > - Benefit of the redundancy concept is seen more on=20 > distributed systems or a system having at least two cards=20 > (ex: 2 route processor cards) which BFD can run actively. > > - Benefit of the redundancy concept is also seen more on=20 > those BFD sessions which aren't tied to specific physical=20 > interfaces (ex: multihop, logical/virtual interfaces).=20 > > - Redundancy concept is applicable to both SW and HW based BFD. > >=20 > > Scope of use case has limitations, in terms of system=20 > architecture as well as BFD type, but for those that this=20 > applies to, I still do see great benefits. > >=20 > >> We still have a possibility of colliding with existing sessions if=20 > >> the remote side makes use of the reserved value. Bumping=20 > the version=20 > >> number is an obvious fix but if we're going to that extent=20 > we need to=20 > >> think more carefully about the full work we'd want under=20 > such a rev. > >=20 > > I still do not see any implementations which cannot support=20 > few more reserved discriminators. But a node speaking to=20 > another which doesn't support added reserved discriminator=20 > range can certainly cause undesired collision. And I agree=20 > that bumping the version number would solve this easily. > >=20 > > Regards, > > Nobo > >=20 >=20 > = From manav.bhatia@alcatel-lucent.com Sun May 26 21:51:49 2013 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 7D63521F92F5 for ; Sun, 26 May 2013 21:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39PaBOz4mkq1 for ; Sun, 26 May 2013 21:51:42 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8621F92EB for ; Sun, 26 May 2013 21:51:42 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4R4pfYl011109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 26 May 2013 23:51:41 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4R4pe06009707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 00:51:40 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 27 May 2013 00:51:40 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Mon, 27 May 2013 12:50:46 +0800 From: "Bhatia, Manav (Manav)" To: Marc Binderberger , Jeffrey Haas , "Nobo Akiya (nobo)" Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWhOVWNAQjdgdjUGntjfJd/sEA5kYbcQAgAAIaoA= Date: Mon, 27 May 2013 04:50:46 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 04:51:49 -0000 Alternatively, we can use the "Authentication Present" bit in the header to= carry this additional block. Once draft-ietf-bfd-generic-crypto-auth-04 becomes a standard we will never= consume any more bits in the Auth Type as this draft introduces a Key ID m= echanism. This means that Auth Type values beyond 8 are available to be use= d for other mechanisms. We could for instance define value 8 meaning a BFD data block. This can the= n be TLV encoded. This is again an example of how BFD can be extended while remaining complet= ely backward compatible -- without bumping the version of BFD. Cheers, Manav > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) > Sent: Monday, May 27, 2013 10:07 AM > To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > Subject: RE: The "version" topic (was: Reserved discriminators?) >=20 > Hi Marc, >=20 > We usually do a version change when there is a very very=20 > substantial upgrade to the protocol - a kind that's usually=20 > non backward compatible. >=20 > If we really want to introduce newer fields to the packet=20 > while being backward compatible then the best approach imo is this: >=20 > You stuff whatever additional information you want in a=20 > special BFD data block immediately at the end of the BFD=20 > packet. Don't include the length of this additional BFD block=20 > in the BFD header. Instead, account for this in the IPv4/IPv6=20 > header length. >=20 > +---------------------+ -- =20 > | IP Header | ^ =20 > | Length =3D HL+X+Y | | Header Length=20 > | | v =20 > +---------------------+ -- =20 > | BFD Header | ^ =20 > | Length =3D X | | =20 > |.....................| | X =20 > | | | =20 > | BFD Data | =20 > | | v =20 > +---------------------+ -- =20 > | | ^ > | BFD Data Block | Y > | | v > +---------------------+ -- >=20 > How this additional BFD data block will be used is beyond the=20 > scope of the discussion right now. You could define that to=20 > be TLV encoded for ensuring easy extensibility. >=20 > Implementations can either implicitly figure out the presence=20 > of the BFD data block by looking at the packet lengths in the=20 > headers or can explicitly be indicated in the BFD header. >=20 > If people think it's a worthwhile idea to pursue then this=20 > can be quickly drafted. >=20 > Cheers, Manav >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org > > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger > > Sent: Sunday, May 26, 2013 6:49 PM > > To: Jeffrey Haas; Nobo Akiya (nobo) > > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > > Subject: The "version" topic (was: Reserved discriminators?) > >=20 > > Hello everyone, > >=20 > > sorry for me delayed response. > >=20 > > Taking a step back. If we would write RFC5880 today then we=20 > probably=20 > > would have reserved a small number of discriminators, e.g.=20 > the first 8=20 > > or 16 values. But RFC5880 is since 3 years out, the=20 > underlying draft=20 > > is even much older. The statement in the Spec is effectively: dear=20 > > implementor, beside the zero value do what you like with=20 > this value. =20 > > We cannot claim back parts of the number space without risking=20 > > problems. > >=20 > > This is why I tend more and more to have clean separation,=20 > be it a new=20 > > IP/UDP port like BFD-on-lags or be it a new version number.=20 > The latter=20 > > faces, I think, largely a psychological problem :-) > >=20 > > Independent if Nobo and me can convince this audience about the=20 > > redundancy concept we propose - working on it - I do see more=20 > > (private) ideas that cover BFD sessions in a general sense,=20 > i.e. cover=20 > > the various RFCs, single-, multi-hop, with/withou label and=20 > so on. In=20 > > all cases I see people spending time to "fiddle about the=20 > bits" of the=20 > > BFD v1 and the IP header. Smart stuff but somehow crazy how=20 > wicked the=20 > > new definitions become, not to mention the difficulties for=20 > > implementations and for interop. > >=20 > >=20 > > Yes, we have a limited number of versions available. Let me=20 > > throw this idea at the BFD audience: the base v2 header would=20 > > look like this: > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 1 0| Subtype | TBD, depending on Subtype | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | My Discriminator | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Your Discriminator | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... | > >=20 > >=20 > > The subtype (the former Diag field) would allow for 32 new=20 > > definitions. Actually I do not hope myself we define so many=20 > > variations ;-) but it opens up room that we do not have with=20 > > the version field alone. > >=20 > > To emphasize: defining a v2 header does not mean v1 is=20 > > obsolete. BFD v1 works great, I'm not trying to replace it=20 > > and whenever it can be used it must be used. > >=20 > > For the other fields above, just quickly my thoughts (if we=20 > > want to dive deeper into this I better write a draft to discuss): > >=20 > > - length field remains in it's position, for ease of implementation > >=20 > > - of course I keep the discriminator concept - or it wouldn't=20 > > be BFD anymore ;-) and I keep them again at the same position=20 > > (the coders of NP, FPGA etc never have enough cycles or=20 > > gates. And these fields are used "in hardware") > >=20 > > - not obvious here but I would define a relatively strict=20 > > upper size limit. I'm not proposing a generic TLV format,=20 > > based on the difficulties I know about implementing really=20 > > fast I/O it is better to have fixed formats, IMHO. > >=20 > >=20 > > Feedback is very welcome. And yes, I have mixed emotions=20 > > myself to let the genie out of the bottle :-) > >=20 > >=20 > > Thanks & Regards, > > Marc > >=20 > >=20 > >=20 > > On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: > >=20 > > > Hello Jeff, et al, > > >=20 > > >> But, if the reserved value was used *only* for the context=20 > > of telling=20 > > >> the remote side "this is your redundant connection", and some=20 > > >> reserved value was used in Down state for Your=20 > > Discriminator to help=20 > > >> with de-multiplexing (e.g. > > >> 1 or 0xffffffff), that would be sufficient. > > >=20 > > > Correct, that was my thoughts. Let's say reserved value=20 > > one(1) was used for shadow session bootstrapping purpose.=20 > > Value one(1) of shadow is equivalent of value zero(0) of=20 > > primary. If "your discriminator =3D=3D 1" is received on a node=20 > > which understands this, then it is to map to shadow session.=20 > > De-multiplex success. > > >=20 > > > - Benefit of the redundancy concept is seen more on=20 > > distributed systems or a system having at least two cards=20 > > (ex: 2 route processor cards) which BFD can run actively. > > > - Benefit of the redundancy concept is also seen more on=20 > > those BFD sessions which aren't tied to specific physical=20 > > interfaces (ex: multihop, logical/virtual interfaces).=20 > > > - Redundancy concept is applicable to both SW and HW based BFD. > > >=20 > > > Scope of use case has limitations, in terms of system=20 > > architecture as well as BFD type, but for those that this=20 > > applies to, I still do see great benefits. > > >=20 > > >> We still have a possibility of colliding with existing=20 > sessions if=20 > > >> the remote side makes use of the reserved value. Bumping=20 > > the version=20 > > >> number is an obvious fix but if we're going to that extent=20 > > we need to=20 > > >> think more carefully about the full work we'd want under=20 > > such a rev. > > >=20 > > > I still do not see any implementations which cannot support=20 > > few more reserved discriminators. But a node speaking to=20 > > another which doesn't support added reserved discriminator=20 > > range can certainly cause undesired collision. And I agree=20 > > that bumping the version number would solve this easily. > > >=20 > > > Regards, > > > Nobo > > >=20 > >=20 > > = From marc@sniff.de Mon May 27 00:02:55 2013 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 3C31521F9476 for ; Mon, 27 May 2013 00:02:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfMvUNvv4NK2 for ; Mon, 27 May 2013 00:02:54 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE721F8FB6 for ; Mon, 27 May 2013 00:02:53 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A5A422AA0F; Mon, 27 May 2013 07:02:50 +0000 (GMT) Subject: Re: The "version" topic (was: Reserved discriminators?) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Mon, 27 May 2013 09:02:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "Jeff Haas \(jhaas@juniper.net\)" , Marc Binderberger , 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, 27 May 2013 07:02:55 -0000 Hello Manav, all fine and good - but I really don't understand this avoidance of a = version change while we start looking for "ways to extend" that all have = the one or other limit. What is the problem of thinking this straight = forward: you have a change - forget "substantial" - or even a = re-interpretation in the header, then it _is_ a new version. Programming-wise this is clean, you have a well-defined indicator that = this packet needs a different treatment. Nothing to conclude, not = depending on IP header length - BFD per se is not IP related - and the = right place is really the BFD header itself when your idea is for the = many BFD usages (IP, IP-less). The "backwards compatible" header I put in my last email was just the = very few first fields. The rest may look very different. Even when the = rest of the header would have the same size of an v1 header but I = interpret them differently, then that's not v1 anymore. Regards, Marc On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: > Alternatively, we can use the "Authentication Present" bit in the = header to carry this additional block. >=20 > Once draft-ietf-bfd-generic-crypto-auth-04 becomes a standard we will = never consume any more bits in the Auth Type as this draft introduces a = Key ID mechanism. This means that Auth Type values beyond 8 are = available to be used for other mechanisms. >=20 > We could for instance define value 8 meaning a BFD data block. This = can then be TLV encoded. >=20 > This is again an example of how BFD can be extended while remaining = completely backward compatible -- without bumping the version of BFD. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org=20 >> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) >> Sent: Monday, May 27, 2013 10:07 AM >> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) >> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >> Subject: RE: The "version" topic (was: Reserved discriminators?) >>=20 >> Hi Marc, >>=20 >> We usually do a version change when there is a very very=20 >> substantial upgrade to the protocol - a kind that's usually=20 >> non backward compatible. >>=20 >> If we really want to introduce newer fields to the packet=20 >> while being backward compatible then the best approach imo is this: >>=20 >> You stuff whatever additional information you want in a=20 >> special BFD data block immediately at the end of the BFD=20 >> packet. Don't include the length of this additional BFD block=20 >> in the BFD header. Instead, account for this in the IPv4/IPv6=20 >> header length. >>=20 >> +---------------------+ -- =20 >> | IP Header | ^ =20 >> | Length =3D HL+X+Y | | Header Length=20 >> | | v =20 >> +---------------------+ -- =20 >> | BFD Header | ^ =20 >> | Length =3D X | | =20 >> |.....................| | X =20 >> | | | =20 >> | BFD Data | =20 >> | | v =20 >> +---------------------+ -- =20 >> | | ^ >> | BFD Data Block | Y >> | | v >> +---------------------+ -- >>=20 >> How this additional BFD data block will be used is beyond the=20 >> scope of the discussion right now. You could define that to=20 >> be TLV encoded for ensuring easy extensibility. >>=20 >> Implementations can either implicitly figure out the presence=20 >> of the BFD data block by looking at the packet lengths in the=20 >> headers or can explicitly be indicated in the BFD header. >>=20 >> If people think it's a worthwhile idea to pursue then this=20 >> can be quickly drafted. >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org >>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger >>> Sent: Sunday, May 26, 2013 6:49 PM >>> To: Jeffrey Haas; Nobo Akiya (nobo) >>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>> Subject: The "version" topic (was: Reserved discriminators?) >>>=20 >>> Hello everyone, >>>=20 >>> sorry for me delayed response. >>>=20 >>> Taking a step back. If we would write RFC5880 today then we=20 >> probably=20 >>> would have reserved a small number of discriminators, e.g.=20 >> the first 8=20 >>> or 16 values. But RFC5880 is since 3 years out, the=20 >> underlying draft=20 >>> is even much older. The statement in the Spec is effectively: dear=20= >>> implementor, beside the zero value do what you like with=20 >> this value. =20 >>> We cannot claim back parts of the number space without risking=20 >>> problems. >>>=20 >>> This is why I tend more and more to have clean separation,=20 >> be it a new=20 >>> IP/UDP port like BFD-on-lags or be it a new version number.=20 >> The latter=20 >>> faces, I think, largely a psychological problem :-) >>>=20 >>> Independent if Nobo and me can convince this audience about the=20 >>> redundancy concept we propose - working on it - I do see more=20 >>> (private) ideas that cover BFD sessions in a general sense,=20 >> i.e. cover=20 >>> the various RFCs, single-, multi-hop, with/withou label and=20 >> so on. In=20 >>> all cases I see people spending time to "fiddle about the=20 >> bits" of the=20 >>> BFD v1 and the IP header. Smart stuff but somehow crazy how=20 >> wicked the=20 >>> new definitions become, not to mention the difficulties for=20 >>> implementations and for interop. >>>=20 >>>=20 >>> Yes, we have a limited number of versions available. Let me=20 >>> throw this idea at the BFD audience: the base v2 header would=20 >>> look like this: >>>=20 >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0 1 0| Subtype | TBD, depending on Subtype | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | My Discriminator | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Your Discriminator | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | ... | >>>=20 >>>=20 >>> The subtype (the former Diag field) would allow for 32 new=20 >>> definitions. Actually I do not hope myself we define so many=20 >>> variations ;-) but it opens up room that we do not have with=20 >>> the version field alone. >>>=20 >>> To emphasize: defining a v2 header does not mean v1 is=20 >>> obsolete. BFD v1 works great, I'm not trying to replace it=20 >>> and whenever it can be used it must be used. >>>=20 >>> For the other fields above, just quickly my thoughts (if we=20 >>> want to dive deeper into this I better write a draft to discuss): >>>=20 >>> - length field remains in it's position, for ease of implementation >>>=20 >>> - of course I keep the discriminator concept - or it wouldn't=20 >>> be BFD anymore ;-) and I keep them again at the same position=20 >>> (the coders of NP, FPGA etc never have enough cycles or=20 >>> gates. And these fields are used "in hardware") >>>=20 >>> - not obvious here but I would define a relatively strict=20 >>> upper size limit. I'm not proposing a generic TLV format,=20 >>> based on the difficulties I know about implementing really=20 >>> fast I/O it is better to have fixed formats, IMHO. >>>=20 >>>=20 >>> Feedback is very welcome. And yes, I have mixed emotions=20 >>> myself to let the genie out of the bottle :-) >>>=20 >>>=20 >>> Thanks & Regards, >>> Marc >>>=20 >>>=20 >>>=20 >>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: >>>=20 >>>> Hello Jeff, et al, >>>>=20 >>>>> But, if the reserved value was used *only* for the context=20 >>> of telling=20 >>>>> the remote side "this is your redundant connection", and some=20 >>>>> reserved value was used in Down state for Your=20 >>> Discriminator to help=20 >>>>> with de-multiplexing (e.g. >>>>> 1 or 0xffffffff), that would be sufficient. >>>>=20 >>>> Correct, that was my thoughts. Let's say reserved value=20 >>> one(1) was used for shadow session bootstrapping purpose.=20 >>> Value one(1) of shadow is equivalent of value zero(0) of=20 >>> primary. If "your discriminator =3D=3D 1" is received on a node=20 >>> which understands this, then it is to map to shadow session.=20 >>> De-multiplex success. >>>>=20 >>>> - Benefit of the redundancy concept is seen more on=20 >>> distributed systems or a system having at least two cards=20 >>> (ex: 2 route processor cards) which BFD can run actively. >>>> - Benefit of the redundancy concept is also seen more on=20 >>> those BFD sessions which aren't tied to specific physical=20 >>> interfaces (ex: multihop, logical/virtual interfaces).=20 >>>> - Redundancy concept is applicable to both SW and HW based BFD. >>>>=20 >>>> Scope of use case has limitations, in terms of system=20 >>> architecture as well as BFD type, but for those that this=20 >>> applies to, I still do see great benefits. >>>>=20 >>>>> We still have a possibility of colliding with existing=20 >> sessions if=20 >>>>> the remote side makes use of the reserved value. Bumping=20 >>> the version=20 >>>>> number is an obvious fix but if we're going to that extent=20 >>> we need to=20 >>>>> think more carefully about the full work we'd want under=20 >>> such a rev. >>>>=20 >>>> I still do not see any implementations which cannot support=20 >>> few more reserved discriminators. But a node speaking to=20 >>> another which doesn't support added reserved discriminator=20 >>> range can certainly cause undesired collision. And I agree=20 >>> that bumping the version number would solve this easily. >>>>=20 >>>> Regards, >>>> Nobo >>>>=20 >>>=20 >>>=20 From manav.bhatia@alcatel-lucent.com Mon May 27 00:17:33 2013 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 334F621F9452 for ; Mon, 27 May 2013 00:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUwBgFiSosZX for ; Mon, 27 May 2013 00:17:26 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 67CEF21F949F for ; Mon, 27 May 2013 00:17:26 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r4R7HOAt020598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2013 02:17:24 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r4R7HM9L031469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 03:17:23 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 27 May 2013 03:17:10 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Mon, 27 May 2013 15:17:06 +0800 From: "Bhatia, Manav (Manav)" To: Marc Binderberger Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWqgvWNAQjdgdjUGntjfJd/sEA5kYm1nw Date: Mon, 27 May 2013 07:17:06 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> In-Reply-To: <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Jeff Haas \(jhaas@juniper.net\)" , Marc Binderberger , "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, 27 May 2013 07:17:33 -0000 Hi Marc, Backward incompatibility is HUGE issue (especially since BFD is usually don= e in HW)! :) The BFD version 2 would only work when all participating devic= es have upgraded to the new version. All currently deployed routers will dr= op these packets as they would consider the version field as invalid. So, t= here must be a very sound reason for taking such a drastic and a radical st= ep - I don't think we have heard any that warrants such a significant chang= e! With my proposal you can incrementally add newer extensions as the earlier = boxes would simply ignore this extended data block that carries the new stu= ff. If youre not comfortable with adding stuff after the BFD payload then we ca= n always take up an Auth Type (say 9) which can then be used to carry all t= he other interesting stuff. Cheers, Manav > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de]=20 > Sent: Monday, May 27, 2013 12:33 PM > To: Bhatia, Manav (Manav) > Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas=20 > (jhaas@juniper.net); rtg-bfd@ietf.org; Marc Binderberger > Subject: Re: The "version" topic (was: Reserved discriminators?) >=20 > Hello Manav, >=20 > all fine and good - but I really don't understand this=20 > avoidance of a version change while we start looking for=20 > "ways to extend" that all have the one or other limit. What=20 > is the problem of thinking this straight forward: you have a=20 > change - forget "substantial" - or even a re-interpretation=20 > in the header, then it _is_ a new version. >=20 > Programming-wise this is clean, you have a well-defined=20 > indicator that this packet needs a different treatment.=20 > Nothing to conclude, not depending on IP header length - BFD=20 > per se is not IP related - and the right place is really the=20 > BFD header itself when your idea is for the many BFD usages=20 > (IP, IP-less). >=20 > The "backwards compatible" header I put in my last email was=20 > just the very few first fields. The rest may look very=20 > different. Even when the rest of the header would have the=20 > same size of an v1 header but I interpret them differently,=20 > then that's not v1 anymore. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: >=20 > > Alternatively, we can use the "Authentication Present" bit=20 > in the header to carry this additional block. > >=20 > > Once draft-ietf-bfd-generic-crypto-auth-04 becomes a=20 > standard we will never consume any more bits in the Auth Type=20 > as this draft introduces a Key ID mechanism. This means that=20 > Auth Type values beyond 8 are available to be used for other=20 > mechanisms. > >=20 > > We could for instance define value 8 meaning a BFD data=20 > block. This can then be TLV encoded. > >=20 > > This is again an example of how BFD can be extended while=20 > remaining completely backward compatible -- without bumping=20 > the version of BFD. > >=20 > > Cheers, Manav > >=20 > >> -----Original Message----- > >> From: rtg-bfd-bounces@ietf.org > >> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia,=20 > Manav (Manav) > >> Sent: Monday, May 27, 2013 10:07 AM > >> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > >> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >> Subject: RE: The "version" topic (was: Reserved discriminators?) > >>=20 > >> Hi Marc, > >>=20 > >> We usually do a version change when there is a very very=20 > substantial=20 > >> upgrade to the protocol - a kind that's usually non backward=20 > >> compatible. > >>=20 > >> If we really want to introduce newer fields to the packet=20 > while being=20 > >> backward compatible then the best approach imo is this: > >>=20 > >> You stuff whatever additional information you want in a=20 > special BFD=20 > >> data block immediately at the end of the BFD packet. Don't include=20 > >> the length of this additional BFD block in the BFD header.=20 > Instead,=20 > >> account for this in the IPv4/IPv6 header length. > >>=20 > >> +---------------------+ -- =20 > >> | IP Header | ^ =20 > >> | Length =3D HL+X+Y | | Header Length=20 > >> | | v =20 > >> +---------------------+ -- =20 > >> | BFD Header | ^ =20 > >> | Length =3D X | | =20 > >> |.....................| | X =20 > >> | | | =20 > >> | BFD Data | =20 > >> | | v =20 > >> +---------------------+ -- =20 > >> | | ^ > >> | BFD Data Block | Y > >> | | v > >> +---------------------+ -- > >>=20 > >> How this additional BFD data block will be used is beyond=20 > the scope=20 > >> of the discussion right now. You could define that to be=20 > TLV encoded=20 > >> for ensuring easy extensibility. > >>=20 > >> Implementations can either implicitly figure out the=20 > presence of the=20 > >> BFD data block by looking at the packet lengths in the=20 > headers or can=20 > >> explicitly be indicated in the BFD header. > >>=20 > >> If people think it's a worthwhile idea to pursue then this can be=20 > >> quickly drafted. > >>=20 > >> Cheers, Manav > >>=20 > >>> -----Original Message----- > >>> From: rtg-bfd-bounces@ietf.org > >>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger > >>> Sent: Sunday, May 26, 2013 6:49 PM > >>> To: Jeffrey Haas; Nobo Akiya (nobo) > >>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>> Subject: The "version" topic (was: Reserved discriminators?) > >>>=20 > >>> Hello everyone, > >>>=20 > >>> sorry for me delayed response. > >>>=20 > >>> Taking a step back. If we would write RFC5880 today then we > >> probably > >>> would have reserved a small number of discriminators, e.g.=20 > >> the first 8 > >>> or 16 values. But RFC5880 is since 3 years out, the > >> underlying draft > >>> is even much older. The statement in the Spec is=20 > effectively: dear=20 > >>> implementor, beside the zero value do what you like with > >> this value. =20 > >>> We cannot claim back parts of the number space without risking=20 > >>> problems. > >>>=20 > >>> This is why I tend more and more to have clean separation, > >> be it a new > >>> IP/UDP port like BFD-on-lags or be it a new version number.=20 > >> The latter > >>> faces, I think, largely a psychological problem :-) > >>>=20 > >>> Independent if Nobo and me can convince this audience about the=20 > >>> redundancy concept we propose - working on it - I do see more > >>> (private) ideas that cover BFD sessions in a general sense, > >> i.e. cover > >>> the various RFCs, single-, multi-hop, with/withou label and > >> so on. In > >>> all cases I see people spending time to "fiddle about the > >> bits" of the > >>> BFD v1 and the IP header. Smart stuff but somehow crazy how > >> wicked the > >>> new definitions become, not to mention the difficulties for=20 > >>> implementations and for interop. > >>>=20 > >>>=20 > >>> Yes, we have a limited number of versions available. Let me throw=20 > >>> this idea at the BFD audience: the base v2 header would look like=20 > >>> this: > >>>=20 > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |0 1 0| Subtype | TBD, depending on Subtype | =20 > Length | > >>> =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | My Discriminator =20 > | > >>> =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Your Discriminator =20 > | > >>> =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | ... =20 > | > >>>=20 > >>>=20 > >>> The subtype (the former Diag field) would allow for 32 new=20 > >>> definitions. Actually I do not hope myself we define so many=20 > >>> variations ;-) but it opens up room that we do not have with the=20 > >>> version field alone. > >>>=20 > >>> To emphasize: defining a v2 header does not mean v1 is=20 > obsolete. BFD=20 > >>> v1 works great, I'm not trying to replace it and whenever=20 > it can be=20 > >>> used it must be used. > >>>=20 > >>> For the other fields above, just quickly my thoughts (if=20 > we want to=20 > >>> dive deeper into this I better write a draft to discuss): > >>>=20 > >>> - length field remains in it's position, for ease of=20 > implementation > >>>=20 > >>> - of course I keep the discriminator concept - or it=20 > wouldn't be BFD=20 > >>> anymore ;-) and I keep them again at the same position=20 > (the coders=20 > >>> of NP, FPGA etc never have enough cycles or gates. And=20 > these fields=20 > >>> are used "in hardware") > >>>=20 > >>> - not obvious here but I would define a relatively strict=20 > upper size=20 > >>> limit. I'm not proposing a generic TLV format, based on the=20 > >>> difficulties I know about implementing really fast I/O it=20 > is better=20 > >>> to have fixed formats, IMHO. > >>>=20 > >>>=20 > >>> Feedback is very welcome. And yes, I have mixed emotions=20 > myself to=20 > >>> let the genie out of the bottle :-) > >>>=20 > >>>=20 > >>> Thanks & Regards, > >>> Marc > >>>=20 > >>>=20 > >>>=20 > >>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: > >>>=20 > >>>> Hello Jeff, et al, > >>>>=20 > >>>>> But, if the reserved value was used *only* for the context > >>> of telling > >>>>> the remote side "this is your redundant connection", and some=20 > >>>>> reserved value was used in Down state for Your > >>> Discriminator to help > >>>>> with de-multiplexing (e.g. > >>>>> 1 or 0xffffffff), that would be sufficient. > >>>>=20 > >>>> Correct, that was my thoughts. Let's say reserved value > >>> one(1) was used for shadow session bootstrapping purpose.=20 > >>> Value one(1) of shadow is equivalent of value zero(0) of=20 > primary. If=20 > >>> "your discriminator =3D=3D 1" is received on a node which understands= =20 > >>> this, then it is to map to shadow session. > >>> De-multiplex success. > >>>>=20 > >>>> - Benefit of the redundancy concept is seen more on > >>> distributed systems or a system having at least two cards > >>> (ex: 2 route processor cards) which BFD can run actively. > >>>> - Benefit of the redundancy concept is also seen more on > >>> those BFD sessions which aren't tied to specific physical=20 > interfaces=20 > >>> (ex: multihop, logical/virtual interfaces). > >>>> - Redundancy concept is applicable to both SW and HW based BFD. > >>>>=20 > >>>> Scope of use case has limitations, in terms of system > >>> architecture as well as BFD type, but for those that this applies=20 > >>> to, I still do see great benefits. > >>>>=20 > >>>>> We still have a possibility of colliding with existing > >> sessions if > >>>>> the remote side makes use of the reserved value. Bumping > >>> the version > >>>>> number is an obvious fix but if we're going to that extent > >>> we need to > >>>>> think more carefully about the full work we'd want under > >>> such a rev. > >>>>=20 > >>>> I still do not see any implementations which cannot support > >>> few more reserved discriminators. But a node speaking to another=20 > >>> which doesn't support added reserved discriminator range can=20 > >>> certainly cause undesired collision. And I agree that bumping the=20 > >>> version number would solve this easily. > >>>>=20 > >>>> Regards, > >>>> Nobo > >>>>=20 > >>>=20 > >>>=20 >=20 > = From marc@sniff.de Mon May 27 00:33:41 2013 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 05ADB21F8B45 for ; Mon, 27 May 2013 00:33:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hp32ny+UuZO for ; Mon, 27 May 2013 00:33:39 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 222FA21F93A6 for ; Mon, 27 May 2013 00:33:37 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E13EB2AA0F; Mon, 27 May 2013 07:33:34 +0000 (GMT) Subject: Re: The "version" topic (was: Reserved discriminators?) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Mon, 27 May 2013 09:33:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 07:33:41 -0000 Hello Manav, > Backward incompatibility is HUGE issue that's why I talk about a version increase - not that the = incompatibility must be automatically a huge issue - to cleanly separate = things. > (especially since BFD is usually done in HW)! :) I have hardware implementations in mind as well. Exactly because you are = potentially less flexible in "hacking something in" it's important to = separate things. Besides: "usually" ... then we would see more really fast BFD = implementations out there, something that just started really. No, = 50msec interval is not really fast ;-) > The BFD version 2 would only work when all participating devices have = upgraded to the new version. There is still this misunderstanding that v2 means we deprecate v1. We = don't. What we talk are new features. They will of course only work in = an interoperable way when all participants in the setup support it - = this has nothing to do with version numbers. > All currently deployed routers will drop these packets as they would = consider the version field as invalid. Exactly that is the beauty, yes. If someone does not implement a new = feature then please please drop the packet.=20 > So, there must be a very sound reason for taking such a drastic and a = radical step - I don't think we have heard any that warrants such a = significant change! Manav, there is no reason naming this "drastic", "radical" or whatever. = When we introduce a new UDP port then equipment not supporting it is = dropping these packets too as no one is listening to it. Haven't seen = any such comments in such a case (and yes, when you can do it with a new UDP port plus v1 then we go with = v1. Not all cases can be covered this way though) > With my proposal you can incrementally add newer extensions as the = earlier boxes would simply ignore this extended data block that carries = the new stuff. Wrong. If the length is not correct then the packet is likely dropped. = If the packet is not dropped then you are in an undefined area and can = only hope for a "reasonable" behaviour. Exactly such an undefined area = is what I want to avoid. Nor is processing of the new packet what you = want in all cases. > If youre not comfortable with adding stuff after the BFD payload then = we can always take up an Auth Type (say 9) which can then be used to = carry all the other interesting stuff. what has this to do with auth? This is what I name a "hack", sorry. = It's exactly my problem, we "work around" instead of addressing a = problem straight forward. (I'm not surprised you bring up auth as this is an area you heavily work = on ;-) Regards, Marc >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de]=20 >> Sent: Monday, May 27, 2013 12:33 PM >> To: Bhatia, Manav (Manav) >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas=20 >> (jhaas@juniper.net); rtg-bfd@ietf.org; Marc Binderberger >> Subject: Re: The "version" topic (was: Reserved discriminators?) >>=20 >> Hello Manav, >>=20 >> all fine and good - but I really don't understand this=20 >> avoidance of a version change while we start looking for=20 >> "ways to extend" that all have the one or other limit. What=20 >> is the problem of thinking this straight forward: you have a=20 >> change - forget "substantial" - or even a re-interpretation=20 >> in the header, then it _is_ a new version. >>=20 >> Programming-wise this is clean, you have a well-defined=20 >> indicator that this packet needs a different treatment.=20 >> Nothing to conclude, not depending on IP header length - BFD=20 >> per se is not IP related - and the right place is really the=20 >> BFD header itself when your idea is for the many BFD usages=20 >> (IP, IP-less). >>=20 >> The "backwards compatible" header I put in my last email was=20 >> just the very few first fields. The rest may look very=20 >> different. Even when the rest of the header would have the=20 >> same size of an v1 header but I interpret them differently,=20 >> then that's not v1 anymore. >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: >>=20 >>> Alternatively, we can use the "Authentication Present" bit=20 >> in the header to carry this additional block. >>>=20 >>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a=20 >> standard we will never consume any more bits in the Auth Type=20 >> as this draft introduces a Key ID mechanism. This means that=20 >> Auth Type values beyond 8 are available to be used for other=20 >> mechanisms. >>>=20 >>> We could for instance define value 8 meaning a BFD data=20 >> block. This can then be TLV encoded. >>>=20 >>> This is again an example of how BFD can be extended while=20 >> remaining completely backward compatible -- without bumping=20 >> the version of BFD. >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org >>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia,=20 >> Manav (Manav) >>>> Sent: Monday, May 27, 2013 10:07 AM >>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) >>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>> Subject: RE: The "version" topic (was: Reserved discriminators?) >>>>=20 >>>> Hi Marc, >>>>=20 >>>> We usually do a version change when there is a very very=20 >> substantial=20 >>>> upgrade to the protocol - a kind that's usually non backward=20 >>>> compatible. >>>>=20 >>>> If we really want to introduce newer fields to the packet=20 >> while being=20 >>>> backward compatible then the best approach imo is this: >>>>=20 >>>> You stuff whatever additional information you want in a=20 >> special BFD=20 >>>> data block immediately at the end of the BFD packet. Don't include=20= >>>> the length of this additional BFD block in the BFD header.=20 >> Instead,=20 >>>> account for this in the IPv4/IPv6 header length. >>>>=20 >>>> +---------------------+ -- =20 >>>> | IP Header | ^ =20 >>>> | Length =3D HL+X+Y | | Header Length=20 >>>> | | v =20 >>>> +---------------------+ -- =20 >>>> | BFD Header | ^ =20 >>>> | Length =3D X | | =20 >>>> |.....................| | X =20 >>>> | | | =20 >>>> | BFD Data | =20 >>>> | | v =20 >>>> +---------------------+ -- =20 >>>> | | ^ >>>> | BFD Data Block | Y >>>> | | v >>>> +---------------------+ -- >>>>=20 >>>> How this additional BFD data block will be used is beyond=20 >> the scope=20 >>>> of the discussion right now. You could define that to be=20 >> TLV encoded=20 >>>> for ensuring easy extensibility. >>>>=20 >>>> Implementations can either implicitly figure out the=20 >> presence of the=20 >>>> BFD data block by looking at the packet lengths in the=20 >> headers or can=20 >>>> explicitly be indicated in the BFD header. >>>>=20 >>>> If people think it's a worthwhile idea to pursue then this can be=20= >>>> quickly drafted. >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org >>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger >>>>> Sent: Sunday, May 26, 2013 6:49 PM >>>>> To: Jeffrey Haas; Nobo Akiya (nobo) >>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>>> Subject: The "version" topic (was: Reserved discriminators?) >>>>>=20 >>>>> Hello everyone, >>>>>=20 >>>>> sorry for me delayed response. >>>>>=20 >>>>> Taking a step back. If we would write RFC5880 today then we >>>> probably >>>>> would have reserved a small number of discriminators, e.g.=20 >>>> the first 8 >>>>> or 16 values. But RFC5880 is since 3 years out, the >>>> underlying draft >>>>> is even much older. The statement in the Spec is=20 >> effectively: dear=20 >>>>> implementor, beside the zero value do what you like with >>>> this value. =20 >>>>> We cannot claim back parts of the number space without risking=20 >>>>> problems. >>>>>=20 >>>>> This is why I tend more and more to have clean separation, >>>> be it a new >>>>> IP/UDP port like BFD-on-lags or be it a new version number.=20 >>>> The latter >>>>> faces, I think, largely a psychological problem :-) >>>>>=20 >>>>> Independent if Nobo and me can convince this audience about the=20 >>>>> redundancy concept we propose - working on it - I do see more >>>>> (private) ideas that cover BFD sessions in a general sense, >>>> i.e. cover >>>>> the various RFCs, single-, multi-hop, with/withou label and >>>> so on. In >>>>> all cases I see people spending time to "fiddle about the >>>> bits" of the >>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how >>>> wicked the >>>>> new definitions become, not to mention the difficulties for=20 >>>>> implementations and for interop. >>>>>=20 >>>>>=20 >>>>> Yes, we have a limited number of versions available. Let me throw=20= >>>>> this idea at the BFD audience: the base v2 header would look like=20= >>>>> this: >>>>>=20 >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0 1 0| Subtype | TBD, depending on Subtype | =20 >> Length | >>>>>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | My Discriminator =20 >> | >>>>>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Your Discriminator =20 >> | >>>>>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | ... =20 >> | >>>>>=20 >>>>>=20 >>>>> The subtype (the former Diag field) would allow for 32 new=20 >>>>> definitions. Actually I do not hope myself we define so many=20 >>>>> variations ;-) but it opens up room that we do not have with the=20= >>>>> version field alone. >>>>>=20 >>>>> To emphasize: defining a v2 header does not mean v1 is=20 >> obsolete. BFD=20 >>>>> v1 works great, I'm not trying to replace it and whenever=20 >> it can be=20 >>>>> used it must be used. >>>>>=20 >>>>> For the other fields above, just quickly my thoughts (if=20 >> we want to=20 >>>>> dive deeper into this I better write a draft to discuss): >>>>>=20 >>>>> - length field remains in it's position, for ease of=20 >> implementation >>>>>=20 >>>>> - of course I keep the discriminator concept - or it=20 >> wouldn't be BFD=20 >>>>> anymore ;-) and I keep them again at the same position=20 >> (the coders=20 >>>>> of NP, FPGA etc never have enough cycles or gates. And=20 >> these fields=20 >>>>> are used "in hardware") >>>>>=20 >>>>> - not obvious here but I would define a relatively strict=20 >> upper size=20 >>>>> limit. I'm not proposing a generic TLV format, based on the=20 >>>>> difficulties I know about implementing really fast I/O it=20 >> is better=20 >>>>> to have fixed formats, IMHO. >>>>>=20 >>>>>=20 >>>>> Feedback is very welcome. And yes, I have mixed emotions=20 >> myself to=20 >>>>> let the genie out of the bottle :-) >>>>>=20 >>>>>=20 >>>>> Thanks & Regards, >>>>> Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: >>>>>=20 >>>>>> Hello Jeff, et al, >>>>>>=20 >>>>>>> But, if the reserved value was used *only* for the context >>>>> of telling >>>>>>> the remote side "this is your redundant connection", and some=20 >>>>>>> reserved value was used in Down state for Your >>>>> Discriminator to help >>>>>>> with de-multiplexing (e.g. >>>>>>> 1 or 0xffffffff), that would be sufficient. >>>>>>=20 >>>>>> Correct, that was my thoughts. Let's say reserved value >>>>> one(1) was used for shadow session bootstrapping purpose.=20 >>>>> Value one(1) of shadow is equivalent of value zero(0) of=20 >> primary. If=20 >>>>> "your discriminator =3D=3D 1" is received on a node which = understands=20 >>>>> this, then it is to map to shadow session. >>>>> De-multiplex success. >>>>>>=20 >>>>>> - Benefit of the redundancy concept is seen more on >>>>> distributed systems or a system having at least two cards >>>>> (ex: 2 route processor cards) which BFD can run actively. >>>>>> - Benefit of the redundancy concept is also seen more on >>>>> those BFD sessions which aren't tied to specific physical=20 >> interfaces=20 >>>>> (ex: multihop, logical/virtual interfaces). >>>>>> - Redundancy concept is applicable to both SW and HW based BFD. >>>>>>=20 >>>>>> Scope of use case has limitations, in terms of system >>>>> architecture as well as BFD type, but for those that this applies=20= >>>>> to, I still do see great benefits. >>>>>>=20 >>>>>>> We still have a possibility of colliding with existing >>>> sessions if >>>>>>> the remote side makes use of the reserved value. Bumping >>>>> the version >>>>>>> number is an obvious fix but if we're going to that extent >>>>> we need to >>>>>>> think more carefully about the full work we'd want under >>>>> such a rev. >>>>>>=20 >>>>>> I still do not see any implementations which cannot support >>>>> few more reserved discriminators. But a node speaking to another=20= >>>>> which doesn't support added reserved discriminator range can=20 >>>>> certainly cause undesired collision. And I agree that bumping the=20= >>>>> version number would solve this easily. >>>>>>=20 >>>>>> Regards, >>>>>> Nobo >>>>>>=20 >>>>>=20 >>>>>=20 >>=20 >>=20 From manav.bhatia@alcatel-lucent.com Mon May 27 01:00:40 2013 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 A216421F911B for ; Mon, 27 May 2013 01:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.733 X-Spam-Level: X-Spam-Status: No, score=-9.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6d+eDBHAzrN for ; Mon, 27 May 2013 01:00:33 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C7C4921F90EF for ; Mon, 27 May 2013 01:00:33 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4R80U6x001217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2013 03:00:30 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4R80OKq012093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 04:00:29 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 27 May 2013 04:00:23 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Mon, 27 May 2013 16:00:20 +0800 From: "Bhatia, Manav (Manav)" To: Marc Binderberger Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWqgvWNAQjdgdjUGntjfJd/sEA5kYo7Y7gAAFFhA= Date: Mon, 27 May 2013 08:00:20 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> In-Reply-To: <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 08:00:40 -0000 Hi Marc, The "hack" that I have suggested already exists in OSPF!:) You can read RFC= 5613 for more sordid details. There are vendors that are shipping code sup= porting this. I wager that if they were able to work around the IP length i= ssues in OSPF, then doing the same in BFD will not be too difficult! Would it help if 5880bis redefines the "Auth Present" bit as "BFD data bloc= k", where BFD data block is TLV encoded. The first 8 type values would indi= cate that a certain kind of authentication scheme is employed. The other va= lues would mean something else. Cheers, Manav > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de]=20 > Sent: Monday, May 27, 2013 1:03 PM > To: Bhatia, Manav (Manav) > Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas=20 > (jhaas@juniper.net); rtg-bfd@ietf.org > Subject: Re: The "version" topic (was: Reserved discriminators?) >=20 > Hello Manav, >=20 > > Backward incompatibility is HUGE issue >=20 > that's why I talk about a version increase - not that the=20 > incompatibility must be automatically a huge issue - to=20 > cleanly separate things. >=20 > > (especially since BFD is usually done in HW)! :) >=20 > I have hardware implementations in mind as well. Exactly=20 > because you are potentially less flexible in "hacking=20 > something in" it's important to separate things. >=20 > Besides: "usually" ... then we would see more really fast BFD=20 > implementations out there, something that just started=20 > really. No, 50msec interval is not really fast ;-) >=20 >=20 > > The BFD version 2 would only work when all participating=20 > devices have upgraded to the new version. >=20 > There is still this misunderstanding that v2 means we=20 > deprecate v1. We don't. What we talk are new features. They=20 > will of course only work in an interoperable way when all=20 > participants in the setup support it - this has nothing to do=20 > with version numbers. >=20 >=20 > > All currently deployed routers will drop these packets as=20 > they would consider the version field as invalid. >=20 > Exactly that is the beauty, yes. If someone does not=20 > implement a new feature then please please drop the packet.=20 >=20 >=20 > > So, there must be a very sound reason for taking such a=20 > drastic and a radical step - I don't think we have heard any=20 > that warrants such a significant change! >=20 > Manav, there is no reason naming this "drastic", "radical" or=20 > whatever. When we introduce a new UDP port then equipment not=20 > supporting it is dropping these packets too as no one is=20 > listening to it. Haven't seen any such comments in such a=20 > case (and yes, when you can do it with a new UDP port plus v1=20 > then we go with v1. Not all cases can be covered this way though) >=20 >=20 > > With my proposal you can incrementally add newer extensions=20 > as the earlier boxes would simply ignore this extended data=20 > block that carries the new stuff. >=20 > Wrong. If the length is not correct then the packet is likely=20 > dropped. If the packet is not dropped then you are in an=20 > undefined area and can only hope for a "reasonable"=20 > behaviour. Exactly such an undefined area is what I want to=20 > avoid. Nor is processing of the new packet what you want in all cases. >=20 >=20 > > If youre not comfortable with adding stuff after the BFD=20 > payload then we can always take up an Auth Type (say 9) which=20 > can then be used to carry all the other interesting stuff. >=20 > what has this to do with auth? This is what I name a "hack",=20 > sorry. It's exactly my problem, we "work around" instead of=20 > addressing a problem straight forward. > (I'm not surprised you bring up auth as this is an area you=20 > heavily work on ;-) >=20 >=20 > Regards, Marc >=20 >=20 > >=20 > > Cheers, Manav > >=20 > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Monday, May 27, 2013 12:33 PM > >> To: Bhatia, Manav (Manav) > >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas=20 > (jhaas@juniper.net);=20 > >> rtg-bfd@ietf.org; Marc Binderberger > >> Subject: Re: The "version" topic (was: Reserved discriminators?) > >>=20 > >> Hello Manav, > >>=20 > >> all fine and good - but I really don't understand this=20 > avoidance of a=20 > >> version change while we start looking for "ways to extend"=20 > that all=20 > >> have the one or other limit. What is the problem of thinking this=20 > >> straight forward: you have a change - forget "substantial"=20 > - or even=20 > >> a re-interpretation in the header, then it _is_ a new version. > >>=20 > >> Programming-wise this is clean, you have a well-defined indicator=20 > >> that this packet needs a different treatment. > >> Nothing to conclude, not depending on IP header length -=20 > BFD per se=20 > >> is not IP related - and the right place is really the BFD header=20 > >> itself when your idea is for the many BFD usages (IP, IP-less). > >>=20 > >> The "backwards compatible" header I put in my last email=20 > was just the=20 > >> very few first fields. The rest may look very different. Even when=20 > >> the rest of the header would have the same size of an v1=20 > header but I=20 > >> interpret them differently, then that's not v1 anymore. > >>=20 > >>=20 > >> Regards, Marc > >>=20 > >>=20 > >>=20 > >> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: > >>=20 > >>> Alternatively, we can use the "Authentication Present" bit=20 > >> in the header to carry this additional block. > >>>=20 > >>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a=20 > >> standard we will never consume any more bits in the Auth Type=20 > >> as this draft introduces a Key ID mechanism. This means that=20 > >> Auth Type values beyond 8 are available to be used for other=20 > >> mechanisms. > >>>=20 > >>> We could for instance define value 8 meaning a BFD data=20 > >> block. This can then be TLV encoded. > >>>=20 > >>> This is again an example of how BFD can be extended while=20 > >> remaining completely backward compatible -- without bumping=20 > >> the version of BFD. > >>>=20 > >>> Cheers, Manav > >>>=20 > >>>> -----Original Message----- > >>>> From: rtg-bfd-bounces@ietf.org > >>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia,=20 > >> Manav (Manav) > >>>> Sent: Monday, May 27, 2013 10:07 AM > >>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > >>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>> Subject: RE: The "version" topic (was: Reserved discriminators?) > >>>>=20 > >>>> Hi Marc, > >>>>=20 > >>>> We usually do a version change when there is a very very=20 > >> substantial=20 > >>>> upgrade to the protocol - a kind that's usually non backward=20 > >>>> compatible. > >>>>=20 > >>>> If we really want to introduce newer fields to the packet=20 > >> while being=20 > >>>> backward compatible then the best approach imo is this: > >>>>=20 > >>>> You stuff whatever additional information you want in a=20 > >> special BFD=20 > >>>> data block immediately at the end of the BFD packet.=20 > Don't include=20 > >>>> the length of this additional BFD block in the BFD header.=20 > >> Instead,=20 > >>>> account for this in the IPv4/IPv6 header length. > >>>>=20 > >>>> +---------------------+ -- =20 > >>>> | IP Header | ^ =20 > >>>> | Length =3D HL+X+Y | | Header Length=20 > >>>> | | v =20 > >>>> +---------------------+ -- =20 > >>>> | BFD Header | ^ =20 > >>>> | Length =3D X | | =20 > >>>> |.....................| | X =20 > >>>> | | | =20 > >>>> | BFD Data | =20 > >>>> | | v =20 > >>>> +---------------------+ -- =20 > >>>> | | ^ > >>>> | BFD Data Block | Y > >>>> | | v > >>>> +---------------------+ -- > >>>>=20 > >>>> How this additional BFD data block will be used is beyond=20 > >> the scope=20 > >>>> of the discussion right now. You could define that to be=20 > >> TLV encoded=20 > >>>> for ensuring easy extensibility. > >>>>=20 > >>>> Implementations can either implicitly figure out the=20 > >> presence of the=20 > >>>> BFD data block by looking at the packet lengths in the=20 > >> headers or can=20 > >>>> explicitly be indicated in the BFD header. > >>>>=20 > >>>> If people think it's a worthwhile idea to pursue then=20 > this can be=20 > >>>> quickly drafted. > >>>>=20 > >>>> Cheers, Manav > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: rtg-bfd-bounces@ietf.org > >>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger > >>>>> Sent: Sunday, May 26, 2013 6:49 PM > >>>>> To: Jeffrey Haas; Nobo Akiya (nobo) > >>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>>> Subject: The "version" topic (was: Reserved discriminators?) > >>>>>=20 > >>>>> Hello everyone, > >>>>>=20 > >>>>> sorry for me delayed response. > >>>>>=20 > >>>>> Taking a step back. If we would write RFC5880 today then we > >>>> probably > >>>>> would have reserved a small number of discriminators, e.g.=20 > >>>> the first 8 > >>>>> or 16 values. But RFC5880 is since 3 years out, the > >>>> underlying draft > >>>>> is even much older. The statement in the Spec is=20 > >> effectively: dear=20 > >>>>> implementor, beside the zero value do what you like with > >>>> this value. =20 > >>>>> We cannot claim back parts of the number space without risking=20 > >>>>> problems. > >>>>>=20 > >>>>> This is why I tend more and more to have clean separation, > >>>> be it a new > >>>>> IP/UDP port like BFD-on-lags or be it a new version number.=20 > >>>> The latter > >>>>> faces, I think, largely a psychological problem :-) > >>>>>=20 > >>>>> Independent if Nobo and me can convince this audience about the=20 > >>>>> redundancy concept we propose - working on it - I do see more > >>>>> (private) ideas that cover BFD sessions in a general sense, > >>>> i.e. cover > >>>>> the various RFCs, single-, multi-hop, with/withou label and > >>>> so on. In > >>>>> all cases I see people spending time to "fiddle about the > >>>> bits" of the > >>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how > >>>> wicked the > >>>>> new definitions become, not to mention the difficulties for=20 > >>>>> implementations and for interop. > >>>>>=20 > >>>>>=20 > >>>>> Yes, we have a limited number of versions available.=20 > Let me throw=20 > >>>>> this idea at the BFD audience: the base v2 header would=20 > look like=20 > >>>>> this: > >>>>>=20 > >>>>> 0 1 2 3 > >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6=20 > 7 8 9 0 1 > >>>>>=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>> |0 1 0| Subtype | TBD, depending on Subtype | =20 > >> Length | > >>>>>=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>> | My Discriminator =20 > >> | > >>>>>=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>> | Your Discriminator =20 > >> | > >>>>>=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>> | ... =20 > >> | > >>>>>=20 > >>>>>=20 > >>>>> The subtype (the former Diag field) would allow for 32 new=20 > >>>>> definitions. Actually I do not hope myself we define so many=20 > >>>>> variations ;-) but it opens up room that we do not have=20 > with the=20 > >>>>> version field alone. > >>>>>=20 > >>>>> To emphasize: defining a v2 header does not mean v1 is=20 > >> obsolete. BFD=20 > >>>>> v1 works great, I'm not trying to replace it and whenever=20 > >> it can be=20 > >>>>> used it must be used. > >>>>>=20 > >>>>> For the other fields above, just quickly my thoughts (if=20 > >> we want to=20 > >>>>> dive deeper into this I better write a draft to discuss): > >>>>>=20 > >>>>> - length field remains in it's position, for ease of=20 > >> implementation > >>>>>=20 > >>>>> - of course I keep the discriminator concept - or it=20 > >> wouldn't be BFD=20 > >>>>> anymore ;-) and I keep them again at the same position=20 > >> (the coders=20 > >>>>> of NP, FPGA etc never have enough cycles or gates. And=20 > >> these fields=20 > >>>>> are used "in hardware") > >>>>>=20 > >>>>> - not obvious here but I would define a relatively strict=20 > >> upper size=20 > >>>>> limit. I'm not proposing a generic TLV format, based on the=20 > >>>>> difficulties I know about implementing really fast I/O it=20 > >> is better=20 > >>>>> to have fixed formats, IMHO. > >>>>>=20 > >>>>>=20 > >>>>> Feedback is very welcome. And yes, I have mixed emotions=20 > >> myself to=20 > >>>>> let the genie out of the bottle :-) > >>>>>=20 > >>>>>=20 > >>>>> Thanks & Regards, > >>>>> Marc > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: > >>>>>=20 > >>>>>> Hello Jeff, et al, > >>>>>>=20 > >>>>>>> But, if the reserved value was used *only* for the context > >>>>> of telling > >>>>>>> the remote side "this is your redundant connection", and some=20 > >>>>>>> reserved value was used in Down state for Your > >>>>> Discriminator to help > >>>>>>> with de-multiplexing (e.g. > >>>>>>> 1 or 0xffffffff), that would be sufficient. > >>>>>>=20 > >>>>>> Correct, that was my thoughts. Let's say reserved value > >>>>> one(1) was used for shadow session bootstrapping purpose.=20 > >>>>> Value one(1) of shadow is equivalent of value zero(0) of=20 > >> primary. If=20 > >>>>> "your discriminator =3D=3D 1" is received on a node which=20 > understands=20 > >>>>> this, then it is to map to shadow session. > >>>>> De-multiplex success. > >>>>>>=20 > >>>>>> - Benefit of the redundancy concept is seen more on > >>>>> distributed systems or a system having at least two cards > >>>>> (ex: 2 route processor cards) which BFD can run actively. > >>>>>> - Benefit of the redundancy concept is also seen more on > >>>>> those BFD sessions which aren't tied to specific physical=20 > >> interfaces=20 > >>>>> (ex: multihop, logical/virtual interfaces). > >>>>>> - Redundancy concept is applicable to both SW and HW based BFD. > >>>>>>=20 > >>>>>> Scope of use case has limitations, in terms of system > >>>>> architecture as well as BFD type, but for those that=20 > this applies=20 > >>>>> to, I still do see great benefits. > >>>>>>=20 > >>>>>>> We still have a possibility of colliding with existing > >>>> sessions if > >>>>>>> the remote side makes use of the reserved value. Bumping > >>>>> the version > >>>>>>> number is an obvious fix but if we're going to that extent > >>>>> we need to > >>>>>>> think more carefully about the full work we'd want under > >>>>> such a rev. > >>>>>>=20 > >>>>>> I still do not see any implementations which cannot support > >>>>> few more reserved discriminators. But a node speaking=20 > to another=20 > >>>>> which doesn't support added reserved discriminator range can=20 > >>>>> certainly cause undesired collision. And I agree that=20 > bumping the=20 > >>>>> version number would solve this easily. > >>>>>>=20 > >>>>>> Regards, > >>>>>> Nobo > >>>>>>=20 > >>>>>=20 > >>>>>=20 > >>=20 > >>=20 >=20 > = From marc@sniff.de Mon May 27 03:59:05 2013 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 DF97C21F90F1 for ; Mon, 27 May 2013 03:59: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHUYDKIKfFiY for ; Mon, 27 May 2013 03:59:04 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D078F21F9019 for ; Mon, 27 May 2013 03:59:03 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A2C142AA0F; Mon, 27 May 2013 10:59:00 +0000 (GMT) Subject: Re: The "version" topic (was: Reserved discriminators?) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Mon, 27 May 2013 12:58:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 10:59:06 -0000 Hello Manav, oh I'm sure for every proposal you will find someone who did this = already ;-) The point would be really that BFD is not restricted to IP and you would = need to make sure the transport mechanism always has some length field. But I don't think we need this because ... > Would it help if 5880bis redefines the "Auth Present" bit as "BFD data = block", where BFD data block is TLV encoded. The first 8 type values = would indicate that a certain kind of authentication scheme is employed. = The other values would mean something else. ... this would be a much cleaner approach. As written in our private = communication I still think that the version approach is a better fit, = at least for cases where you don't need or don't want all the v1 fields. = Such a proposal then describes how to not use such fields, where to = deviate from v1 ... practically you _do_ describe a new version (if you = definition of version isn't too strict) but with the risk of some = implementations stumbling as it's still a v1 packet. Now the version approach is based on one assumption: that = implementations do check the version field. Due to the BFD history with = v0 and v1 I have taken this for granted Anyway, I'm glad we have the discussion. And I hope for more opinions = :-) Best regards, Marc On 2013-05-27, at 10:00 , Bhatia, Manav (Manav) wrote: > Hi Marc, >=20 > The "hack" that I have suggested already exists in OSPF!:) You can = read RFC 5613 for more sordid details. There are vendors that are = shipping code supporting this. I wager that if they were able to work = around the IP length issues in OSPF, then doing the same in BFD will not = be too difficult! >=20 > Would it help if 5880bis redefines the "Auth Present" bit as "BFD data = block", where BFD data block is TLV encoded. The first 8 type values = would indicate that a certain kind of authentication scheme is employed. = The other values would mean something else. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de]=20 >> Sent: Monday, May 27, 2013 1:03 PM >> To: Bhatia, Manav (Manav) >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas=20 >> (jhaas@juniper.net); rtg-bfd@ietf.org >> Subject: Re: The "version" topic (was: Reserved discriminators?) >>=20 >> Hello Manav, >>=20 >>> Backward incompatibility is HUGE issue >>=20 >> that's why I talk about a version increase - not that the=20 >> incompatibility must be automatically a huge issue - to=20 >> cleanly separate things. >>=20 >>> (especially since BFD is usually done in HW)! :) >>=20 >> I have hardware implementations in mind as well. Exactly=20 >> because you are potentially less flexible in "hacking=20 >> something in" it's important to separate things. >>=20 >> Besides: "usually" ... then we would see more really fast BFD=20 >> implementations out there, something that just started=20 >> really. No, 50msec interval is not really fast ;-) >>=20 >>=20 >>> The BFD version 2 would only work when all participating=20 >> devices have upgraded to the new version. >>=20 >> There is still this misunderstanding that v2 means we=20 >> deprecate v1. We don't. What we talk are new features. They=20 >> will of course only work in an interoperable way when all=20 >> participants in the setup support it - this has nothing to do=20 >> with version numbers. >>=20 >>=20 >>> All currently deployed routers will drop these packets as=20 >> they would consider the version field as invalid. >>=20 >> Exactly that is the beauty, yes. If someone does not=20 >> implement a new feature then please please drop the packet.=20 >>=20 >>=20 >>> So, there must be a very sound reason for taking such a=20 >> drastic and a radical step - I don't think we have heard any=20 >> that warrants such a significant change! >>=20 >> Manav, there is no reason naming this "drastic", "radical" or=20 >> whatever. When we introduce a new UDP port then equipment not=20 >> supporting it is dropping these packets too as no one is=20 >> listening to it. Haven't seen any such comments in such a=20 >> case (and yes, when you can do it with a new UDP port plus v1=20 >> then we go with v1. Not all cases can be covered this way though) >>=20 >>=20 >>> With my proposal you can incrementally add newer extensions=20 >> as the earlier boxes would simply ignore this extended data=20 >> block that carries the new stuff. >>=20 >> Wrong. If the length is not correct then the packet is likely=20 >> dropped. If the packet is not dropped then you are in an=20 >> undefined area and can only hope for a "reasonable"=20 >> behaviour. Exactly such an undefined area is what I want to=20 >> avoid. Nor is processing of the new packet what you want in all = cases. >>=20 >>=20 >>> If youre not comfortable with adding stuff after the BFD=20 >> payload then we can always take up an Auth Type (say 9) which=20 >> can then be used to carry all the other interesting stuff. >>=20 >> what has this to do with auth? This is what I name a "hack",=20 >> sorry. It's exactly my problem, we "work around" instead of=20 >> addressing a problem straight forward. >> (I'm not surprised you bring up auth as this is an area you=20 >> heavily work on ;-) >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>> Sent: Monday, May 27, 2013 12:33 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas=20 >> (jhaas@juniper.net);=20 >>>> rtg-bfd@ietf.org; Marc Binderberger >>>> Subject: Re: The "version" topic (was: Reserved discriminators?) >>>>=20 >>>> Hello Manav, >>>>=20 >>>> all fine and good - but I really don't understand this=20 >> avoidance of a=20 >>>> version change while we start looking for "ways to extend"=20 >> that all=20 >>>> have the one or other limit. What is the problem of thinking this=20= >>>> straight forward: you have a change - forget "substantial"=20 >> - or even=20 >>>> a re-interpretation in the header, then it _is_ a new version. >>>>=20 >>>> Programming-wise this is clean, you have a well-defined indicator=20= >>>> that this packet needs a different treatment. >>>> Nothing to conclude, not depending on IP header length -=20 >> BFD per se=20 >>>> is not IP related - and the right place is really the BFD header=20 >>>> itself when your idea is for the many BFD usages (IP, IP-less). >>>>=20 >>>> The "backwards compatible" header I put in my last email=20 >> was just the=20 >>>> very few first fields. The rest may look very different. Even when=20= >>>> the rest of the header would have the same size of an v1=20 >> header but I=20 >>>> interpret them differently, then that's not v1 anymore. >>>>=20 >>>>=20 >>>> Regards, Marc >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> Alternatively, we can use the "Authentication Present" bit=20 >>>> in the header to carry this additional block. >>>>>=20 >>>>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a=20 >>>> standard we will never consume any more bits in the Auth Type=20 >>>> as this draft introduces a Key ID mechanism. This means that=20 >>>> Auth Type values beyond 8 are available to be used for other=20 >>>> mechanisms. >>>>>=20 >>>>> We could for instance define value 8 meaning a BFD data=20 >>>> block. This can then be TLV encoded. >>>>>=20 >>>>> This is again an example of how BFD can be extended while=20 >>>> remaining completely backward compatible -- without bumping=20 >>>> the version of BFD. >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: rtg-bfd-bounces@ietf.org >>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia,=20 >>>> Manav (Manav) >>>>>> Sent: Monday, May 27, 2013 10:07 AM >>>>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) >>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>>>> Subject: RE: The "version" topic (was: Reserved discriminators?) >>>>>>=20 >>>>>> Hi Marc, >>>>>>=20 >>>>>> We usually do a version change when there is a very very=20 >>>> substantial=20 >>>>>> upgrade to the protocol - a kind that's usually non backward=20 >>>>>> compatible. >>>>>>=20 >>>>>> If we really want to introduce newer fields to the packet=20 >>>> while being=20 >>>>>> backward compatible then the best approach imo is this: >>>>>>=20 >>>>>> You stuff whatever additional information you want in a=20 >>>> special BFD=20 >>>>>> data block immediately at the end of the BFD packet.=20 >> Don't include=20 >>>>>> the length of this additional BFD block in the BFD header.=20 >>>> Instead,=20 >>>>>> account for this in the IPv4/IPv6 header length. >>>>>>=20 >>>>>> +---------------------+ -- =20 >>>>>> | IP Header | ^ =20 >>>>>> | Length =3D HL+X+Y | | Header Length=20 >>>>>> | | v =20 >>>>>> +---------------------+ -- =20 >>>>>> | BFD Header | ^ =20 >>>>>> | Length =3D X | | =20 >>>>>> |.....................| | X =20 >>>>>> | | | =20 >>>>>> | BFD Data | =20 >>>>>> | | v =20 >>>>>> +---------------------+ -- =20 >>>>>> | | ^ >>>>>> | BFD Data Block | Y >>>>>> | | v >>>>>> +---------------------+ -- >>>>>>=20 >>>>>> How this additional BFD data block will be used is beyond=20 >>>> the scope=20 >>>>>> of the discussion right now. You could define that to be=20 >>>> TLV encoded=20 >>>>>> for ensuring easy extensibility. >>>>>>=20 >>>>>> Implementations can either implicitly figure out the=20 >>>> presence of the=20 >>>>>> BFD data block by looking at the packet lengths in the=20 >>>> headers or can=20 >>>>>> explicitly be indicated in the BFD header. >>>>>>=20 >>>>>> If people think it's a worthwhile idea to pursue then=20 >> this can be=20 >>>>>> quickly drafted. >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger >>>>>>> Sent: Sunday, May 26, 2013 6:49 PM >>>>>>> To: Jeffrey Haas; Nobo Akiya (nobo) >>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>>>>> Subject: The "version" topic (was: Reserved discriminators?) >>>>>>>=20 >>>>>>> Hello everyone, >>>>>>>=20 >>>>>>> sorry for me delayed response. >>>>>>>=20 >>>>>>> Taking a step back. If we would write RFC5880 today then we >>>>>> probably >>>>>>> would have reserved a small number of discriminators, e.g.=20 >>>>>> the first 8 >>>>>>> or 16 values. But RFC5880 is since 3 years out, the >>>>>> underlying draft >>>>>>> is even much older. The statement in the Spec is=20 >>>> effectively: dear=20 >>>>>>> implementor, beside the zero value do what you like with >>>>>> this value. =20 >>>>>>> We cannot claim back parts of the number space without risking=20= >>>>>>> problems. >>>>>>>=20 >>>>>>> This is why I tend more and more to have clean separation, >>>>>> be it a new >>>>>>> IP/UDP port like BFD-on-lags or be it a new version number.=20 >>>>>> The latter >>>>>>> faces, I think, largely a psychological problem :-) >>>>>>>=20 >>>>>>> Independent if Nobo and me can convince this audience about the=20= >>>>>>> redundancy concept we propose - working on it - I do see more >>>>>>> (private) ideas that cover BFD sessions in a general sense, >>>>>> i.e. cover >>>>>>> the various RFCs, single-, multi-hop, with/withou label and >>>>>> so on. In >>>>>>> all cases I see people spending time to "fiddle about the >>>>>> bits" of the >>>>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how >>>>>> wicked the >>>>>>> new definitions become, not to mention the difficulties for=20 >>>>>>> implementations and for interop. >>>>>>>=20 >>>>>>>=20 >>>>>>> Yes, we have a limited number of versions available.=20 >> Let me throw=20 >>>>>>> this idea at the BFD audience: the base v2 header would=20 >> look like=20 >>>>>>> this: >>>>>>>=20 >>>>>>> 0 1 2 3 >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6=20 >> 7 8 9 0 1 >>>>>>>=20 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> |0 1 0| Subtype | TBD, depending on Subtype | =20 >>>> Length | >>>>>>>=20 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | My Discriminator =20 >>>> | >>>>>>>=20 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Your Discriminator =20 >>>> | >>>>>>>=20 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | ... =20 >>>> | >>>>>>>=20 >>>>>>>=20 >>>>>>> The subtype (the former Diag field) would allow for 32 new=20 >>>>>>> definitions. Actually I do not hope myself we define so many=20 >>>>>>> variations ;-) but it opens up room that we do not have=20 >> with the=20 >>>>>>> version field alone. >>>>>>>=20 >>>>>>> To emphasize: defining a v2 header does not mean v1 is=20 >>>> obsolete. BFD=20 >>>>>>> v1 works great, I'm not trying to replace it and whenever=20 >>>> it can be=20 >>>>>>> used it must be used. >>>>>>>=20 >>>>>>> For the other fields above, just quickly my thoughts (if=20 >>>> we want to=20 >>>>>>> dive deeper into this I better write a draft to discuss): >>>>>>>=20 >>>>>>> - length field remains in it's position, for ease of=20 >>>> implementation >>>>>>>=20 >>>>>>> - of course I keep the discriminator concept - or it=20 >>>> wouldn't be BFD=20 >>>>>>> anymore ;-) and I keep them again at the same position=20 >>>> (the coders=20 >>>>>>> of NP, FPGA etc never have enough cycles or gates. And=20 >>>> these fields=20 >>>>>>> are used "in hardware") >>>>>>>=20 >>>>>>> - not obvious here but I would define a relatively strict=20 >>>> upper size=20 >>>>>>> limit. I'm not proposing a generic TLV format, based on the=20 >>>>>>> difficulties I know about implementing really fast I/O it=20 >>>> is better=20 >>>>>>> to have fixed formats, IMHO. >>>>>>>=20 >>>>>>>=20 >>>>>>> Feedback is very welcome. And yes, I have mixed emotions=20 >>>> myself to=20 >>>>>>> let the genie out of the bottle :-) >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks & Regards, >>>>>>> Marc >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: >>>>>>>=20 >>>>>>>> Hello Jeff, et al, >>>>>>>>=20 >>>>>>>>> But, if the reserved value was used *only* for the context >>>>>>> of telling >>>>>>>>> the remote side "this is your redundant connection", and some=20= >>>>>>>>> reserved value was used in Down state for Your >>>>>>> Discriminator to help >>>>>>>>> with de-multiplexing (e.g. >>>>>>>>> 1 or 0xffffffff), that would be sufficient. >>>>>>>>=20 >>>>>>>> Correct, that was my thoughts. Let's say reserved value >>>>>>> one(1) was used for shadow session bootstrapping purpose.=20 >>>>>>> Value one(1) of shadow is equivalent of value zero(0) of=20 >>>> primary. If=20 >>>>>>> "your discriminator =3D=3D 1" is received on a node which=20 >> understands=20 >>>>>>> this, then it is to map to shadow session. >>>>>>> De-multiplex success. >>>>>>>>=20 >>>>>>>> - Benefit of the redundancy concept is seen more on >>>>>>> distributed systems or a system having at least two cards >>>>>>> (ex: 2 route processor cards) which BFD can run actively. >>>>>>>> - Benefit of the redundancy concept is also seen more on >>>>>>> those BFD sessions which aren't tied to specific physical=20 >>>> interfaces=20 >>>>>>> (ex: multihop, logical/virtual interfaces). >>>>>>>> - Redundancy concept is applicable to both SW and HW based BFD. >>>>>>>>=20 >>>>>>>> Scope of use case has limitations, in terms of system >>>>>>> architecture as well as BFD type, but for those that=20 >> this applies=20 >>>>>>> to, I still do see great benefits. >>>>>>>>=20 >>>>>>>>> We still have a possibility of colliding with existing >>>>>> sessions if >>>>>>>>> the remote side makes use of the reserved value. Bumping >>>>>>> the version >>>>>>>>> number is an obvious fix but if we're going to that extent >>>>>>> we need to >>>>>>>>> think more carefully about the full work we'd want under >>>>>>> such a rev. >>>>>>>>=20 >>>>>>>> I still do not see any implementations which cannot support >>>>>>> few more reserved discriminators. But a node speaking=20 >> to another=20 >>>>>>> which doesn't support added reserved discriminator range can=20 >>>>>>> certainly cause undesired collision. And I agree that=20 >> bumping the=20 >>>>>>> version number would solve this easily. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Nobo >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From manav.bhatia@alcatel-lucent.com Mon May 27 05:19:02 2013 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 DF8EA21F8AF7 for ; Mon, 27 May 2013 05:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.079 X-Spam-Level: X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t2aLV-NOoR3 for ; Mon, 27 May 2013 05:18:56 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3342821F93E0 for ; Mon, 27 May 2013 05:18:56 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r4RCIt66029334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2013 07:18:55 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r4RCIqEP004263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 08:18:53 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 27 May 2013 08:18:52 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Mon, 27 May 2013 20:18:49 +0800 From: "Bhatia, Manav (Manav)" To: G Vengada Prasad , Marc Binderberger Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWtNEWNAQjdgdjUGntjfJd/sEA5kY8uvQ Date: Mon, 27 May 2013 12:18:48 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C30353D2@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <1369656667.17325.YahooMailNeo@web162502.mail.bf1.yahoo.com> In-Reply-To: <1369656667.17325.YahooMailNeo@web162502.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Jeff Haas , "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, 27 May 2013 12:19:03 -0000 Prasad, =20 WHat i had meant when i had said that packets will get dropped is that spea= kers who only understand v1 will not be able to parse the v2 packet. Obviou= sly, v1 sessions will continue to work. =20 Also, i was having this as a general discussion about how BFD could be exte= nded given that it has fixed fields -- I did not have any specific draft in= my mind. =20 Cheers, Manav ________________________________ From: G Vengada Prasad [mailto:gvprasad@yahoo.com]=20 Sent: Monday, May 27, 2013 5:41 PM To: Marc Binderberger; Bhatia, Manav (Manav) Cc: Jeff Haas; rtg-bfd@ietf.org Subject: Re: The "version" topic (was: Reserved discriminators?) Hello all, One more point that may be worth clarifying here,=20 =20 >> All currently deployed routers will drop these packets as they would co= nsider the version field as invalid. >Exactly that is the beauty, yes. If someone does not implement a new feat= ure then please please drop the packet.=20 My understanding is that there would be _no_ impact to the v1 sessions due= ot the mechanism(s) proposed in the draft - they would continue to work. I= n other words if device-A supporting (v1 and) v2 type sessions and device-B= supporting v1-only were to interop, the common minimum i.e. v1 BFD session= s would continue to work as before. device-A may keep trying (forever?) to = establish v2 sessions but not get to Up state for v2 while v1 continues to = work as before. Hence there would be no loss of v1 BFD functionality. This = applies for any type of BFD session (Single-hop, multi-hop, MPLS label base= d, VCCV etc). Marc/ Nobo, Please correct me if my understanding is inconsistent with the draft. =20 Thanks Prasad =20 =09 From nobo@cisco.com Mon May 27 07:10:14 2013 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 80DCD21F8FCB for ; Mon, 27 May 2013 07:10:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qauF9aZLS3-3 for ; Mon, 27 May 2013 07:10:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5561721F9003 for ; Mon, 27 May 2013 07:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17973; q=dns/txt; s=iport; t=1369663808; x=1370873408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CxqibOozZI8HvvEo00CHYxNi7I+/X1Je4eh4Of3nJ1M=; b=OiD4lNn/L5eQJwBP4EulRqe/JGLEVNdFeqimVsBy7dFbFtmdxMzlUIwx RtJswkzd/KEWBra2gU5u4JjIAafDqYnHTZ8KdRuCrx37Chd6ossvcXpMm Smsv3sQJHLdAYDOMnMs5lQpQl6f1v7BacZE0T6ppfsPDWVJflfut6oWsv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALRoo1GtJXG//2dsb2JhbABagmchwjSBBRZ0giMBAQEEOi0SDAQCAQgRAQMBAQEKCwkJBzIUAwYIAgQOBQiIBQG9bI1bCgESdDEHBgSCaWEDqHuDD4FoAQEHFx8 X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="215380416" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 27 May 2013 14:10:07 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4REA7J2032511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 14:10:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 27 May 2013 09:10:06 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , "Bhatia, Manav (Manav)" Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWpXi351GHcKw4ESBj+lSSrfkkJkY7wUAgAAEAwCAAASTAIAAB4EAgAAx5QD//+CUIA== Date: Mon, 27 May 2013 14:10:06 +0000 Message-ID: References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 14:10:14 -0000 Hello Marc, Manav, As much as I would like to see more pieces to play with, I honestly don't s= ee sufficient reasons to define such (generically speaking). No matter how smart _how_ is, we will not get WG consensus without people s= eeing great value(s). We should go back to discussing _if_ we need to define such. Regards, Nobo P.S. Your email is very interesting, I'll have to grab coffee and read this= couple of more times. > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, May 27, 2013 6:59 AM > To: Bhatia, Manav (Manav) > Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); rtg- > bfd@ietf.org > Subject: Re: The "version" topic (was: Reserved discriminators?) >=20 > Hello Manav, >=20 > oh I'm sure for every proposal you will find someone who did this already= ;-) >=20 > The point would be really that BFD is not restricted to IP and you would > need to make sure the transport mechanism always has some length field. >=20 > But I don't think we need this because ... >=20 > > Would it help if 5880bis redefines the "Auth Present" bit as "BFD data > block", where BFD data block is TLV encoded. The first 8 type values woul= d > indicate that a certain kind of authentication scheme is employed. The > other values would mean something else. >=20 >=20 > ... this would be a much cleaner approach. As written in our private > communication I still think that the version approach is a better fit, at= least > for cases where you don't need or don't want all the v1 fields. Such a > proposal then describes how to not use such fields, where to deviate from > v1 ... practically you _do_ describe a new version (if you definition of > version isn't too strict) but with the risk of some implementations stumb= ling > as it's still a v1 packet. >=20 > Now the version approach is based on one assumption: that > implementations do check the version field. Due to the BFD history with v= 0 > and v1 I have taken this for granted >=20 >=20 > Anyway, I'm glad we have the discussion. And I hope for more opinions :-) >=20 >=20 > Best regards, > Marc >=20 >=20 >=20 >=20 > On 2013-05-27, at 10:00 , Bhatia, Manav (Manav) wrote: >=20 > > Hi Marc, > > > > The "hack" that I have suggested already exists in OSPF!:) You can read= RFC > 5613 for more sordid details. There are vendors that are shipping code > supporting this. I wager that if they were able to work around the IP len= gth > issues in OSPF, then doing the same in BFD will not be too difficult! > > > > Would it help if 5880bis redefines the "Auth Present" bit as "BFD data > block", where BFD data block is TLV encoded. The first 8 type values woul= d > indicate that a certain kind of authentication scheme is employed. The > other values would mean something else. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Monday, May 27, 2013 1:03 PM > >> To: Bhatia, Manav (Manav) > >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); > >> rtg-bfd@ietf.org > >> Subject: Re: The "version" topic (was: Reserved discriminators?) > >> > >> Hello Manav, > >> > >>> Backward incompatibility is HUGE issue > >> > >> that's why I talk about a version increase - not that the > >> incompatibility must be automatically a huge issue - to cleanly > >> separate things. > >> > >>> (especially since BFD is usually done in HW)! :) > >> > >> I have hardware implementations in mind as well. Exactly because you > >> are potentially less flexible in "hacking something in" it's > >> important to separate things. > >> > >> Besides: "usually" ... then we would see more really fast BFD > >> implementations out there, something that just started really. No, > >> 50msec interval is not really fast ;-) > >> > >> > >>> The BFD version 2 would only work when all participating > >> devices have upgraded to the new version. > >> > >> There is still this misunderstanding that v2 means we deprecate v1. > >> We don't. What we talk are new features. They will of course only > >> work in an interoperable way when all participants in the setup > >> support it - this has nothing to do with version numbers. > >> > >> > >>> All currently deployed routers will drop these packets as > >> they would consider the version field as invalid. > >> > >> Exactly that is the beauty, yes. If someone does not > >> implement a new feature then please please drop the packet. > >> > >> > >>> So, there must be a very sound reason for taking such a > >> drastic and a radical step - I don't think we have heard any > >> that warrants such a significant change! > >> > >> Manav, there is no reason naming this "drastic", "radical" or > >> whatever. When we introduce a new UDP port then equipment not > >> supporting it is dropping these packets too as no one is > >> listening to it. Haven't seen any such comments in such a > >> case (and yes, when you can do it with a new UDP port plus v1 > >> then we go with v1. Not all cases can be covered this way though) > >> > >> > >>> With my proposal you can incrementally add newer extensions > >> as the earlier boxes would simply ignore this extended data > >> block that carries the new stuff. > >> > >> Wrong. If the length is not correct then the packet is likely > >> dropped. If the packet is not dropped then you are in an > >> undefined area and can only hope for a "reasonable" > >> behaviour. Exactly such an undefined area is what I want to > >> avoid. Nor is processing of the new packet what you want in all cases. > >> > >> > >>> If youre not comfortable with adding stuff after the BFD > >> payload then we can always take up an Auth Type (say 9) which > >> can then be used to carry all the other interesting stuff. > >> > >> what has this to do with auth? This is what I name a "hack", > >> sorry. It's exactly my problem, we "work around" instead of > >> addressing a problem straight forward. > >> (I'm not surprised you bring up auth as this is an area you > >> heavily work on ;-) > >> > >> > >> Regards, Marc > >> > >> > >>> > >>> Cheers, Manav > >>> > >>>> -----Original Message----- > >>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>> Sent: Monday, May 27, 2013 12:33 PM > >>>> To: Bhatia, Manav (Manav) > >>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas > >> (jhaas@juniper.net); > >>>> rtg-bfd@ietf.org; Marc Binderberger > >>>> Subject: Re: The "version" topic (was: Reserved discriminators?) > >>>> > >>>> Hello Manav, > >>>> > >>>> all fine and good - but I really don't understand this > >> avoidance of a > >>>> version change while we start looking for "ways to extend" > >> that all > >>>> have the one or other limit. What is the problem of thinking this > >>>> straight forward: you have a change - forget "substantial" > >> - or even > >>>> a re-interpretation in the header, then it _is_ a new version. > >>>> > >>>> Programming-wise this is clean, you have a well-defined indicator > >>>> that this packet needs a different treatment. > >>>> Nothing to conclude, not depending on IP header length - > >> BFD per se > >>>> is not IP related - and the right place is really the BFD header > >>>> itself when your idea is for the many BFD usages (IP, IP-less). > >>>> > >>>> The "backwards compatible" header I put in my last email > >> was just the > >>>> very few first fields. The rest may look very different. Even when > >>>> the rest of the header would have the same size of an v1 > >> header but I > >>>> interpret them differently, then that's not v1 anymore. > >>>> > >>>> > >>>> Regards, Marc > >>>> > >>>> > >>>> > >>>> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: > >>>> > >>>>> Alternatively, we can use the "Authentication Present" bit > >>>> in the header to carry this additional block. > >>>>> > >>>>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a > >>>> standard we will never consume any more bits in the Auth Type > >>>> as this draft introduces a Key ID mechanism. This means that > >>>> Auth Type values beyond 8 are available to be used for other > >>>> mechanisms. > >>>>> > >>>>> We could for instance define value 8 meaning a BFD data > >>>> block. This can then be TLV encoded. > >>>>> > >>>>> This is again an example of how BFD can be extended while > >>>> remaining completely backward compatible -- without bumping > >>>> the version of BFD. > >>>>> > >>>>> Cheers, Manav > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: rtg-bfd-bounces@ietf.org > >>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, > >>>> Manav (Manav) > >>>>>> Sent: Monday, May 27, 2013 10:07 AM > >>>>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > >>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>>>> Subject: RE: The "version" topic (was: Reserved discriminators?) > >>>>>> > >>>>>> Hi Marc, > >>>>>> > >>>>>> We usually do a version change when there is a very very > >>>> substantial > >>>>>> upgrade to the protocol - a kind that's usually non backward > >>>>>> compatible. > >>>>>> > >>>>>> If we really want to introduce newer fields to the packet > >>>> while being > >>>>>> backward compatible then the best approach imo is this: > >>>>>> > >>>>>> You stuff whatever additional information you want in a > >>>> special BFD > >>>>>> data block immediately at the end of the BFD packet. > >> Don't include > >>>>>> the length of this additional BFD block in the BFD header. > >>>> Instead, > >>>>>> account for this in the IPv4/IPv6 header length. > >>>>>> > >>>>>> +---------------------+ -- > >>>>>> | IP Header | ^ > >>>>>> | Length =3D HL+X+Y | | Header Length > >>>>>> | | v > >>>>>> +---------------------+ -- > >>>>>> | BFD Header | ^ > >>>>>> | Length =3D X | | > >>>>>> |.....................| | X > >>>>>> | | | > >>>>>> | BFD Data | > >>>>>> | | v > >>>>>> +---------------------+ -- > >>>>>> | | ^ > >>>>>> | BFD Data Block | Y > >>>>>> | | v > >>>>>> +---------------------+ -- > >>>>>> > >>>>>> How this additional BFD data block will be used is beyond > >>>> the scope > >>>>>> of the discussion right now. You could define that to be > >>>> TLV encoded > >>>>>> for ensuring easy extensibility. > >>>>>> > >>>>>> Implementations can either implicitly figure out the > >>>> presence of the > >>>>>> BFD data block by looking at the packet lengths in the > >>>> headers or can > >>>>>> explicitly be indicated in the BFD header. > >>>>>> > >>>>>> If people think it's a worthwhile idea to pursue then > >> this can be > >>>>>> quickly drafted. > >>>>>> > >>>>>> Cheers, Manav > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: rtg-bfd-bounces@ietf.org > >>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger > >>>>>>> Sent: Sunday, May 26, 2013 6:49 PM > >>>>>>> To: Jeffrey Haas; Nobo Akiya (nobo) > >>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>>>>> Subject: The "version" topic (was: Reserved discriminators?) > >>>>>>> > >>>>>>> Hello everyone, > >>>>>>> > >>>>>>> sorry for me delayed response. > >>>>>>> > >>>>>>> Taking a step back. If we would write RFC5880 today then we > >>>>>> probably > >>>>>>> would have reserved a small number of discriminators, e.g. > >>>>>> the first 8 > >>>>>>> or 16 values. But RFC5880 is since 3 years out, the > >>>>>> underlying draft > >>>>>>> is even much older. The statement in the Spec is > >>>> effectively: dear > >>>>>>> implementor, beside the zero value do what you like with > >>>>>> this value. > >>>>>>> We cannot claim back parts of the number space without risking > >>>>>>> problems. > >>>>>>> > >>>>>>> This is why I tend more and more to have clean separation, > >>>>>> be it a new > >>>>>>> IP/UDP port like BFD-on-lags or be it a new version number. > >>>>>> The latter > >>>>>>> faces, I think, largely a psychological problem :-) > >>>>>>> > >>>>>>> Independent if Nobo and me can convince this audience about the > >>>>>>> redundancy concept we propose - working on it - I do see more > >>>>>>> (private) ideas that cover BFD sessions in a general sense, > >>>>>> i.e. cover > >>>>>>> the various RFCs, single-, multi-hop, with/withou label and > >>>>>> so on. In > >>>>>>> all cases I see people spending time to "fiddle about the > >>>>>> bits" of the > >>>>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how > >>>>>> wicked the > >>>>>>> new definitions become, not to mention the difficulties for > >>>>>>> implementations and for interop. > >>>>>>> > >>>>>>> > >>>>>>> Yes, we have a limited number of versions available. > >> Let me throw > >>>>>>> this idea at the BFD audience: the base v2 header would > >> look like > >>>>>>> this: > >>>>>>> > >>>>>>> 0 1 2 3 > >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >> 7 8 9 0 1 > >>>>>>> > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>> |0 1 0| Subtype | TBD, depending on Subtype | > >>>> Length | > >>>>>>> > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>> | My Discriminator > >>>> | > >>>>>>> > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>> | Your Discriminator > >>>> | > >>>>>>> > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>> | ... > >>>> | > >>>>>>> > >>>>>>> > >>>>>>> The subtype (the former Diag field) would allow for 32 new > >>>>>>> definitions. Actually I do not hope myself we define so many > >>>>>>> variations ;-) but it opens up room that we do not have > >> with the > >>>>>>> version field alone. > >>>>>>> > >>>>>>> To emphasize: defining a v2 header does not mean v1 is > >>>> obsolete. BFD > >>>>>>> v1 works great, I'm not trying to replace it and whenever > >>>> it can be > >>>>>>> used it must be used. > >>>>>>> > >>>>>>> For the other fields above, just quickly my thoughts (if > >>>> we want to > >>>>>>> dive deeper into this I better write a draft to discuss): > >>>>>>> > >>>>>>> - length field remains in it's position, for ease of > >>>> implementation > >>>>>>> > >>>>>>> - of course I keep the discriminator concept - or it > >>>> wouldn't be BFD > >>>>>>> anymore ;-) and I keep them again at the same position > >>>> (the coders > >>>>>>> of NP, FPGA etc never have enough cycles or gates. And > >>>> these fields > >>>>>>> are used "in hardware") > >>>>>>> > >>>>>>> - not obvious here but I would define a relatively strict > >>>> upper size > >>>>>>> limit. I'm not proposing a generic TLV format, based on the > >>>>>>> difficulties I know about implementing really fast I/O it > >>>> is better > >>>>>>> to have fixed formats, IMHO. > >>>>>>> > >>>>>>> > >>>>>>> Feedback is very welcome. And yes, I have mixed emotions > >>>> myself to > >>>>>>> let the genie out of the bottle :-) > >>>>>>> > >>>>>>> > >>>>>>> Thanks & Regards, > >>>>>>> Marc > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: > >>>>>>> > >>>>>>>> Hello Jeff, et al, > >>>>>>>> > >>>>>>>>> But, if the reserved value was used *only* for the context > >>>>>>> of telling > >>>>>>>>> the remote side "this is your redundant connection", and some > >>>>>>>>> reserved value was used in Down state for Your > >>>>>>> Discriminator to help > >>>>>>>>> with de-multiplexing (e.g. > >>>>>>>>> 1 or 0xffffffff), that would be sufficient. > >>>>>>>> > >>>>>>>> Correct, that was my thoughts. Let's say reserved value > >>>>>>> one(1) was used for shadow session bootstrapping purpose. > >>>>>>> Value one(1) of shadow is equivalent of value zero(0) of > >>>> primary. If > >>>>>>> "your discriminator =3D=3D 1" is received on a node which > >> understands > >>>>>>> this, then it is to map to shadow session. > >>>>>>> De-multiplex success. > >>>>>>>> > >>>>>>>> - Benefit of the redundancy concept is seen more on > >>>>>>> distributed systems or a system having at least two cards > >>>>>>> (ex: 2 route processor cards) which BFD can run actively. > >>>>>>>> - Benefit of the redundancy concept is also seen more on > >>>>>>> those BFD sessions which aren't tied to specific physical > >>>> interfaces > >>>>>>> (ex: multihop, logical/virtual interfaces). > >>>>>>>> - Redundancy concept is applicable to both SW and HW based BFD. > >>>>>>>> > >>>>>>>> Scope of use case has limitations, in terms of system > >>>>>>> architecture as well as BFD type, but for those that > >> this applies > >>>>>>> to, I still do see great benefits. > >>>>>>>> > >>>>>>>>> We still have a possibility of colliding with existing > >>>>>> sessions if > >>>>>>>>> the remote side makes use of the reserved value. Bumping > >>>>>>> the version > >>>>>>>>> number is an obvious fix but if we're going to that extent > >>>>>>> we need to > >>>>>>>>> think more carefully about the full work we'd want under > >>>>>>> such a rev. > >>>>>>>> > >>>>>>>> I still do not see any implementations which cannot support > >>>>>>> few more reserved discriminators. But a node speaking > >> to another > >>>>>>> which doesn't support added reserved discriminator range can > >>>>>>> certainly cause undesired collision. And I agree that > >> bumping the > >>>>>>> version number would solve this easily. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Nobo > >>>>>>>> > >>>>>>> > >>>>>>> > >>>> > >>>> > >> > >> From gvprasad@yahoo.com Mon May 27 05:11:15 2013 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 6007821F9260 for ; Mon, 27 May 2013 05:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th2C1nf0IbA4 for ; Mon, 27 May 2013 05:11:08 -0700 (PDT) Received: from nm36-vm8.bullet.mail.bf1.yahoo.com (nm36-vm8.bullet.mail.bf1.yahoo.com [72.30.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2668A21F8C4C for ; Mon, 27 May 2013 05:11:08 -0700 (PDT) Received: from [98.139.212.152] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2013 12:11:07 -0000 Received: from [98.139.212.220] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2013 12:11:07 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 27 May 2013 12:11:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 416479.61609.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 36487 invoked by uid 60001); 27 May 2013 12:11:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1369656667; bh=1qkbmN+e6n6xxI1iRBoMMsWNiVJcI8SEzceTAcFttwI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=mQRUn3soZeSijwhu/pMm1ByjqnAGxtqBtr0Q4VMaQrnvQCmapoCWTp2rQm9k2W20wunzQ8mqD2QeZ2xMuQaZ0lcV8ziBDat0jChGPltGuW1Rn7PGmHegx18ERPxr/pHGg1HSE/+Zrm1nuoqaTu2K6B6bo3kVjOHk1mIcbJssMVk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=h7IwQRaGtPoxIKRkAVO2hSG7+lYGQnVVtdSuvedCZnOYyCNcGkczoRd0auTz8tkzE/rRs3LIpl0zBVuuS9xjgjCDyZw7fo1gU6Yodw5ZNJcX9M27rwujm4qNMLqdZbHFTHbmIYr+dI/UwMKl26ExGd4hhy0uaoQTDqu/w1educY=; X-YMail-OSG: 1zBzSrwVM1nM7q41a4OmYh66yXb2z0ecrboxjGVWgtncFKl cj6dSGFE7hoB4u3U3HxPf5Dy2p30adCSYuBUwow4SbFcfsTbmL9o.vXbaV.q He45Onj9fOXOHbsRzOb0KIcyOmzYxBMTTCK6b1qcNshcF4ow6Mx54mxbBYpy TXIX3Jx9m9mM4XqhLBg09K4udN7JMct2o8ohIrHZxM.OTOvenshQlIY99TBm 6vsvcPXqjySQyfDSJEBJef9xQm7hAMJDG.FzKdlIPfPl7dt7qRX01jk7EE9p cJrbcb3.Skf3xQFbZnn123rPx4DKFCfm7y9xhYY_jWqvOxcUTCyzjgNpBRBe qZrTapGcJCETQZEKzv3sHhm62DTmYNUDPj.u.x1DZKcUCEwn._4u40_Q8EOX _idGfPnS_ftyKucpqCnT.78t1V4TUznmqA4h9g6vbMZrHbOWdleDM3GgmeD_ w_BBNOTOcBwnr5y92zMOULGaierNhwvveeC5fNsRLq1j7cbaQLpSmfWMNG8Z 6A4kf._7b Received: from [72.163.217.104] by web162502.mail.bf1.yahoo.com via HTTP; Mon, 27 May 2013 05:11:07 PDT X-Rocket-MIMEInfo: 002.001, SGVsbG8gYWxsLApPbmUgbW9yZSBwb2ludCB0aGF0IG1heSBiZSB3b3J0aCBjbGFyaWZ5aW5nIGhlcmUsIArCoAo.PiBBbGwgY3VycmVudGx5IGRlcGxveWVkIHJvdXRlcnMgd2lsbCBkcm9wIHRoZXNlCnBhY2tldHMgYXMgdGhleSB3b3VsZCBjb25zaWRlciB0aGUgdmVyc2lvbiBmaWVsZCBhcyBpbnZhbGlkLgo.RXhhY3RseSB0aGF0IGlzIHRoZSBiZWF1dHksIHllcy4gSWYgc29tZW9uZSBkb2VzIG5vdAppbXBsZW1lbnQgYSBuZXcgZmVhdHVyZSB0aGVuIHBsZWFzZSBwbGVhc2UgZHJvcCB0aGUgcGFja2V0LiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 Message-ID: <1369656667.17325.YahooMailNeo@web162502.mail.bf1.yahoo.com> Date: Mon, 27 May 2013 05:11:07 -0700 (PDT) From: G Vengada Prasad Subject: Re: The "version" topic (was: Reserved discriminators?) To: Marc Binderberger , "Manav \(Manav\)" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1314897756-1538230658-1369656667=:17325" X-Mailman-Approved-At: Mon, 27 May 2013 07:16:07 -0700 Cc: Jeff Haas , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: G Vengada Prasad List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:12:09 -0000 ---1314897756-1538230658-1369656667=:17325 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,=0AOne more point that may be worth clarifying here, =0A=A0=0A>> = All currently deployed routers will drop these=0Apackets as they would cons= ider the version field as invalid.=0A>Exactly that is the beauty, yes. If s= omeone does not=0Aimplement a new feature then please please drop the packe= t. =0AMy understanding is that there=A0would be=A0_no_ impact to the v1 ses= sions due ot the mechanism(s) proposed in the draft=A0- they would continue= to work. In other words if device-A supporting (v1 and)=A0v2 type sessions= and device-B supporting v1-only were to interop, the common minimum i.e. v= 1 BFD sessions would continue to work as before. device-A may keep trying (= forever?) to establish v2 sessions but not get to Up state for v2 while v1 = continues to work as before. Hence there would be no loss of v1 BFD functio= nality. This applies=A0for any type of BFD session (Single-hop, multi-hop, = MPLS label based, VCCV etc).=0A=A0=0AMarc/ Nobo,=0A=A0Please correct me if = my understanding is inconsistent with the draft.=0A=A0=0AThanks=0APrasad=0A= =A0=0AHello Manav,=0A=A0=0A> Backward incompatibility is HUGE issue=0A=A0= =0Athat's why I talk about a version increase - not that the=0Aincompatibil= ity must be automatically a huge issue - to cleanly separate=0Athings.=0A= =A0=0A> (especially since BFD is usually done in HW)! :)=0A=A0=0AI have har= dware implementations in mind as well. Exactly=0Abecause you are potentiall= y less flexible in "hacking something in"=0Ait's important to separate thin= gs.=0A=A0=0ABesides: "usually" ... then we would see more=0Areally fast BFD= implementations out there, something that just started really.=0ANo, 50mse= c interval is not really fast ;-)=0A=A0=0A=A0=0A> The BFD version 2 would o= nly work when all=0Aparticipating devices have upgraded to the new version.= =0A=A0=0AThere is still this misunderstanding that v2 means we=0Adeprecate = v1. We don't. What we talk are new features. They will of course only=0Awor= k in an interoperable way when all participants in the setup support it -= =0Athis has nothing to do with version numbers.=0A=A0=0A=A0=0A> All current= ly deployed routers will drop these=0Apackets as they would consider the ve= rsion field as invalid.=0A=A0=0AExactly that is the beauty, yes. If someone= does not=0Aimplement a new feature then please please drop the packet. =0A= =A0=0A=A0=0A> So, there must be a very sound reason for taking=0Asuch a dra= stic and a radical step - I don't think we have heard any that=0Awarrants s= uch a significant change!=0A=A0=0AManav, there is no reason naming this=0A"= drastic", "radical" or whatever. When we introduce a new=0AUDP port then eq= uipment not supporting it is dropping these packets too as no=0Aone is list= ening to it. Haven't seen any such comments in such a case (and yes,=0Awhen= you can do it with a new UDP port plus v1 then we go with v1. Not all=0Aca= ses can be covered this way though)=0A=A0=0A=A0=0A> With my proposal you ca= n incrementally add newer=0Aextensions as the earlier boxes would simply ig= nore this extended data block=0Athat carries the new stuff.=0A=A0=0AWrong. = If the length is not correct then the packet is=0Alikely dropped. If the pa= cket is not dropped then you are in an undefined area=0Aand can only hope f= or a "reasonable" behaviour. Exactly such an=0Aundefined area is what I wan= t to avoid. Nor is processing of the new packet=0Awhat you want in all case= s.=0A=A0=0A=A0=0A> If youre not comfortable with adding stuff after the=0AB= FD payload then we can always take up an Auth Type (say 9) which can then b= e=0Aused to carry all the other interesting stuff.=0A=A0=0Awhat has this to= do with auth?=A0 This is what I name a "hack",=0Asorry. It's exactly my pr= oblem, we "work around" instead of=0Aaddressing a problem straight forward.= =0A(I'm not surprised you bring up auth as this is an area=0Ayou heavily wo= rk on ;-)=0A=A0=0A=A0=0ARegards, Marc=0A=A0=0A=A0=0A> =0A> Cheers, Manav=0A= > =0A>> -----Original Message-----=0A>> From: Marc=0ABinderberger [mailto:m= arc@sniff.de]=0A>> Sent: Monday, May 27, 2013 12:33 PM=0A>> To: Bhatia, Man= av (Manav)=0A>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@junip= er.net); =0A>> rtg-bfd@ietf.org;=0AMarc Binderberger=0A>> Subject: Re: The = "version" topic (was:=0AReserved discriminators?)=0A>> =0A>> Hello Manav,= =0A>> =0A>> all fine and good - but I really don't=0Aunderstand this avoida= nce of a =0A>> version change while we start looking for=0A"ways to extend"= that all =0A>> have the one or other limit. What is the problem=0Aof think= ing this =0A>> straight forward: you have a change - forget=0A"substantial"= - or even =0A>> a re-interpretation in the header, then it _is_=0Aa new ve= rsion.=0A>> =0A>> Programming-wise this is clean, you have a=0Awell-defined= indicator =0A>> that this packet needs a different treatment.=0A>> Nothing= to conclude, not depending on IP header=0Alength - BFD per se =0A>> is not= IP related - and the right place is=0Areally the BFD header =0A>> itself w= hen your idea is for the many BFD usages=0A(IP, IP-less).=0A>> =0A>> The "b= ackwards compatible" header I=0Aput in my last email was just the =0A>> ver= y few first fields. The rest may look very=0Adifferent. Even when =0A>> the= rest of the header would have the same size=0Aof an v1 header but I =0A>> = interpret them differently, then that's not v1=0Aanymore.=0A>> =0A>> =0A>> = Regards, Marc=0A>> =0A>> =0A>> =0A>> On 2013-05-27, at 6:50 , Bhatia, Manav= (Manav)=0Awrote:=0A>> =0A>>> Alternatively, we can use the=0A"Authenticati= on Present" bit =0A>> in the header to carry this additional block.=0A>>> = =0A>>> Once draft-ietf-bfd-generic-crypto-auth-04=0Abecomes a =0A>> standar= d we will never consume any more bits in=0Athe Auth Type =0A>> as this draf= t introduces a Key ID mechanism.=0AThis means that =0A>> Auth Type values b= eyond 8 are available to be=0Aused for other =0A>> mechanisms.=0A>>> =0A>>>= We could for instance define value 8 meaning=0Aa BFD data =0A>> block. Thi= s can then be TLV encoded.=0A>>> =0A>>> This is again an example of how BFD= can be=0Aextended while =0A>> remaining completely backward compatible --= =0Awithout bumping =0A>> the version of BFD.=0A>>> =0A>>> Cheers, Manav=0A>= >> =0A>>>> -----Original Message-----=0A>>>> From: rtg-bfd-bounces@ietf.org= =0A>>>> [mailto:rtg-bfd-bounces@ietf.org] On=0ABehalf Of Bhatia, =0A>> Mana= v (Manav)=0A>>>> Sent: Monday, May 27, 2013 10:07 AM=0A>>>> To: Marc Binder= berger; Jeffrey Haas;=0ANobo Akiya (nobo)=0A>>>> Cc: Jeff Haas (jhaas@junip= er.net); rtg-bfd@ietf.org=0A>>>> Subject: RE: The "version"=0Atopic (was: R= eserved discriminators?)=0A>>>> =0A>>>> Hi Marc,=0A>>>> =0A>>>> We usually = do a version change when=0Athere is a very very =0A>> substantial =0A>>>> u= pgrade to the protocol - a kind that's=0Ausually non backward =0A>>>> compa= tible.=0A>>>> =0A>>>> If we really want to introduce newer=0Afields to the = packet =0A>> while being =0A>>>> backward compatible then the best=0Aapproa= ch imo is this:=0A>>>> =0A>>>> You stuff whatever additional information=0A= you want in a =0A>> special BFD =0A>>>> data block immediately at the end o= f the=0ABFD packet. Don't include =0A>>>> the length of this additional BFD= block=0Ain the BFD header. =0A>> Instead, =0A>>>> account for this in the = IPv4/IPv6 header=0Alength.=0A>>>> =0A>>>>=A0 +---------------------+ --=A0= =A0=A0=A0=A0=A0=A0 =0A>>>>=A0 |=0AIP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= ^=A0=A0=A0=A0=A0 =0A>>>>=A0 |=0ALength =3D HL+X+Y=A0=A0=A0=A0 | | Header L= ength =0A>>>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 | v=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =0A>>>>=A0 +-------------= --------+ --=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =0A>>>>=A0 |=0ABFD=A0 Head= er=A0=A0=A0=A0=A0=A0=A0=A0 | ^=A0=A0=A0=A0=A0 =0A>>>>=A0 |=0ALength =3D X= =A0=A0=A0=A0=A0=A0=A0=A0=A0 | |=A0=A0=A0=A0=A0 =0A>>>>=A0 |................= .....| | X=A0=A0=A0 =0A>>>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 | |=A0=A0=A0=A0=A0 =0A>>>>=A0 |=0ABFD=A0 Data=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 =0A>>>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | v=A0=A0=A0=A0=A0 =0A>>>>=A0 +-------= --------------+ --=A0=A0=A0=A0 =0A>>>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ^=0A>>>>=A0 |=0ABFD Data Block=A0=A0=A0=A0= =A0 | Y=0A>>>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 | v=0A>>>>=A0 +---------------------+ --=0A>>>> =0A>>>> How this add= itional BFD data block will=0Abe used is beyond =0A>> the scope =0A>>>> of = the discussion right now. You could=0Adefine that to be =0A>> TLV encoded = =0A>>>> for ensuring easy extensibility.=0A>>>> =0A>>>> Implementations can= either implicitly=0Afigure out the =0A>> presence of the =0A>>>> BFD data = block by looking at the packet=0Alengths in the =0A>> headers or can =0A>>>= > explicitly be indicated in the BFD=0Aheader.=0A>>>> =0A>>>> If people thi= nk it's a worthwhile idea=0Ato pursue then this can be =0A>>>> quickly draf= ted.=0A>>>> =0A>>>> Cheers, Manav=0A>>>> =0A>>>>> -----Original Message----= -=0A>>>>> From: rtg-bfd-bounces@ietf.org=0A>>>>> [mailto:rtg-bfd-bounces@ie= tf.org] On=0ABehalf Of Marc Binderberger=0A>>>>> Sent: Sunday, May 26, 2013= 6:49 PM=0A>>>>> To: Jeffrey Haas; Nobo Akiya (nobo)=0A>>>>> Cc: Jeff Haas = (jhaas@juniper.net); rtg-bfd@ietf.org=0A>>>>> Subject: The "version"=0Atopi= c (was: Reserved discriminators?)=0A>>>>> =0A>>>>> Hello everyone,=0A>>>>> = =0A>>>>> sorry for me delayed response.=0A>>>>> =0A>>>>> Taking a step back= . If we would=0Awrite RFC5880 today then we=0A>>>> probably=0A>>>>> would h= ave reserved a small number=0Aof discriminators, e.g. =0A>>>> the first 8= =0A>>>>> or 16 values.=A0 But RFC5880 is since 3 years out, the=0A>>>> unde= rlying draft=0A>>>>> is even much older. The statement in=0Athe Spec is =0A= >> effectively: dear =0A>>>>> implementor, beside the zero value=0Ado what = you like with=0A>>>> this value.=A0 =0A>>>>> We cannot claim back parts of = the=0Anumber space without risking =0A>>>>> problems.=0A>>>>> =0A>>>>> This= is why I tend more and more to=0Ahave clean separation,=0A>>>> be it a new= =0A>>>>> IP/UDP port like BFD-on-lags or be=0Ait a new version number. =0A>= >>> The latter=0A>>>>> faces, I think, largely a=0Apsychological problem :-= )=0A>>>>> =0A>>>>> Independent if Nobo and me can=0Aconvince this audience = about the =0A>>>>> redundancy concept we propose -=0Aworking on it - I do s= ee more=0A>>>>> (private) ideas that cover BFD=0Asessions in a general sens= e,=0A>>>> i.e. cover=0A>>>>> the various RFCs, single-,=0Amulti-hop, with/w= ithou label and=0A>>>> so on.=A0 In=0A>>>>> all cases I see people spending= time=0Ato "fiddle about the=0A>>>> bits" of the=0A>>>>> BFD v1 and the IP = header. Smart=0Astuff but somehow crazy how=0A>>>> wicked the=0A>>>>> new d= efinitions become, not to=0Amention the difficulties for =0A>>>>> implement= ations and for interop.=0A>>>>> =0A>>>>> =0A>>>>> Yes, we have a limited nu= mber of=0Aversions available. Let me throw =0A>>>>> this idea at the BFD au= dience: the=0Abase v2 header would look like =0A>>>>> this:=0A>>>>> =0A>>>>= >=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 3=0A>>>>>=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5= 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A>>>>> =0A>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A>>>>>=A0 |0 1 0| Subtype |=A0=A0 TB= D, depending=0Aon Subtype=A0=A0 |=A0=A0=A0 =0A>> Length=A0=A0=A0=A0 |=0A>>>= >> =0A>>=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +=0A>>>>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 My Discriminator=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =0A>>= =A0=A0=A0=A0=A0=A0=A0 |=0A>>>>> =0A>>=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A>>>>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Your=0ADiscriminator=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 =0A>>=A0=A0=A0=A0=A0=A0=A0 |=0A>>>>> =0A>>=0A+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A>>>>>=A0 | ...= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =0A>>=A0=A0=A0=A0=A0=A0=A0 |=0A>>>>> =0A>>>>> =0A>>>>> The subtype (the fo= rmer Diag field)=0Awould allow for 32 new =0A>>>>> definitions. Actually I = do not hope=0Amyself we define so many =0A>>>>> variations ;-) but it opens= up room=0Athat we do not have with the =0A>>>>> version field alone.=0A>>>= >> =0A>>>>> To emphasize: defining a v2 header=0Adoes not mean v1 is =0A>> = obsolete. BFD =0A>>>>> v1 works great, I'm not trying to=0Areplace it and w= henever =0A>> it can be =0A>>>>> used it must be used.=0A>>>>> =0A>>>>> For= the other fields above, just=0Aquickly my thoughts (if =0A>> we want to = =0A>>>>> dive deeper into this I better write=0Aa draft to discuss):=0A>>>>= > =0A>>>>> - length field remains in it's=0Aposition, for ease of =0A>> imp= lementation=0A>>>>> =0A>>>>> - of course I keep the discriminator=0Aconcept= - or it =0A>> wouldn't be BFD =0A>>>>> anymore ;-) and I keep them again a= t=0Athe same position =0A>> (the coders =0A>>>>> of NP, FPGA etc never have= enough=0Acycles or gates. And =0A>> these fields =0A>>>>> are used "in har= dware")=0A>>>>> =0A>>>>> - not obvious here but I would=0Adefine a relative= ly strict =0A>> upper size =0A>>>>> limit. I'm not proposing a generic=0ATL= V format, based on the =0A>>>>> difficulties I know about=0Aimplementing re= ally fast I/O it =0A>> is better =0A>>>>> to have fixed formats, IMHO.=0A>>= >>> =0A>>>>> =0A>>>>> Feedback is very welcome. And yes, I=0Ahave mixed emo= tions =0A>> myself to =0A>>>>> let the genie out of the bottle :-)=0A>>>>> = =0A>>>>> =0A>>>>> Thanks & Regards,=0A>>>>> Marc=0A>>>>> =0A>>>>> =0A>>>>> = =0A>>>>> On 2013-05-17, at 17:35 , Nobo Akiya=0A(nobo) wrote:=0A>>>>> =0A>>= >>>> Hello Jeff, et al,=0A>>>>>> =0A>>>>>>> But, if the reserved value=0Awa= s used *only* for the context=0A>>>>> of telling=0A>>>>>>> the remote side = "this=0Ais your redundant connection", and some =0A>>>>>>> reserved value w= as used in=0ADown state for Your=0A>>>>> Discriminator to help=0A>>>>>>> wi= th de-multiplexing (e.g.=0A>>>>>>> 1 or 0xffffffff), that would=0Abe suffic= ient.=0A>>>>>> =0A>>>>>> Correct, that was my thoughts.=0ALet's say reserve= d value=0A>>>>> one(1) was used for shadow session=0Abootstrapping purpose.= =0A>>>>> Value one(1) of shadow is equivalent=0Aof value zero(0) of =0A>> = primary. If =0A>>>>> "your discriminator =3D=3D 1"=0Ais received on a node = which understands =0A>>>>> this, then it is to map to shadow=0Asession.=0A>= >>>> De-multiplex success.=0A>>>>>> =0A>>>>>> - Benefit of the redundancy= =0Aconcept is seen more on=0A>>>>> distributed systems or a system=0Ahaving= at least two cards=0A>>>>> (ex: 2 route processor cards) which=0ABFD can r= un actively.=0A>>>>>> - Benefit of the redundancy=0Aconcept is also seen mo= re on=0A>>>>> those BFD sessions which aren't tied=0Ato specific physical = =0A>> interfaces =0A>>>>> (ex: multihop, logical/virtual=0Ainterfaces).=0A>= >>>>> - Redundancy concept is=0Aapplicable to both SW and HW based BFD.=0A>= >>>>> =0A>>>>>> Scope of use case has=0Alimitations, in terms of system=0A>= >>>> architecture as well as BFD type,=0Abut for those that this applies = =0A>>>>> to, I still do see great benefits.=0A>>>>>> =0A>>>>>>> We still ha= ve a possibility=0Aof colliding with existing=0A>>>> sessions if=0A>>>>>>> = the remote side makes use of=0Athe reserved value.=A0 Bumping=0A>>>>> the v= ersion=0A>>>>>>> number is an obvious fix but=0Aif we're going to that exte= nt=0A>>>>> we need to=0A>>>>>>> think more carefully about=0Athe full work = we'd want under=0A>>>>> such a rev.=0A>>>>>> =0A>>>>>> I still do not see a= ny=0Aimplementations which cannot support=0A>>>>> few more reserved discrim= inators.=0ABut a node speaking to another =0A>>>>> which doesn't support ad= ded reserved=0Adiscriminator range can =0A>>>>> certainly cause undesired c= ollision.=0AAnd I agree that bumping the =0A>>>>> version number would solv= e this=0Aeasily.=0A>>>>>> =0A>>>>>> Regards,=0A>>>>>> Nobo=0A>>>>>> =0A>>>>= > =0A>>>>> =0A>> =0A>> =0A=A0=0A=0ARegards,=0APrasad. ---1314897756-1538230658-1369656667=:17325 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0AHello a= ll,
One more point that may be worth clarifying here= ,
 
=0A=0A>> All currently deployed routers will drop these=0Apackets = as they would consider the version field as invalid.
=0A=0A>Exactly that is the beauty, yes. If = someone does not=0Aimplement a new feature then please please drop the pack= et.
=0A=0A=0A=0A
My understanding is= that there would be _no_ impact to the v1 sessions due ot the me= chanism(s) proposed in the draft - they would continue to work. In oth= er words if device-A supporting (v1 and) v2 type sessions and device-B= supporting v1-only were to interop, the common minimum i.e. v1 BFD session= s would continue to work as before. device-A may keep trying (forever?) to = establish v2 sessions but not get to Up state for v2 while v1 continues to = work as before. Hence there would be no loss of v1 BFD functionality. This = applies for any type of BFD session (Single-hop, multi-hop, MPLS label= based, VCCV etc).
 
Marc/ Nobo,
 P= lease correct me if my understanding is inconsistent with the draft.
<= div> 
Thanks
Prasad
 
H= ello Manav,
=0A=0A
 
=0A=0A
> Backward incompatibility is HUGE= issue
=0A=0A
 
=0A=0A
that's why I talk about a version increase= - not that the=0Aincompatibility must be automatically a huge issue - to c= leanly separate=0Athings.
=0A=0A
 
=0A=0A
> (especially since = BFD is usually done in HW)! :)
=0A=0A
 
=0A=0A
I have hardware im= plementations in mind as well. Exactly=0Abecause you are potentially less f= lexible in "hacking something in"=0Ait's important to separate things.=
=0A=0A
 
=0A=0A
<= font face=3D"Calibri">Besides: "usually" ... then we would see more=0Areall= y fast BFD implementations out there, something that just started really.= =0ANo, 50msec interval is not really fast ;-)
= =0A=0A
 
=0A=0A
 
=0A=0A
> The BFD version 2 = would only work when all=0Aparticipating devices have upgraded to the new v= ersion.
=0A=0A
 
=0A=0A
There is still this misunderstanding that= v2 means we=0Adeprecate v1. We don't. What we talk are new features. They = will of course only=0Awork in an interoperable way when all participants in= the setup support it -=0Athis has nothing to do with version numbers.=
=0A=0A
=0A=0A
 
=0A=0A
 
=0A=0A
> All currently deployed routers will drop these=0Ap= ackets as they would consider the version field as invalid.
=0A=0A
 
=0A=0A
Exactly that is the beauty, yes. If someone does not=0Aimpleme= nt a new feature then please please drop the packet.
=0A=0A
 
=0A=0A
 
=0A=0A
> So, there m= ust be a very sound reason for taking=0Asuch a drastic and a radical step -= I don't think we have heard any that=0Awarrants such a significant change!=
=0A=0A
 
=0A=0A
Manav, there is no reason naming this=0A"drastic= ", "radical" or whatever. When we introduce a new=0AUDP port then equipment= not supporting it is dropping these packets too as no=0Aone is listening t= o it. Haven't seen any such comments in such a case (and yes,=0Awhen you ca= n do it with a new UDP port plus v1 then we go with v1. Not all=0Acases can= be covered this way though)
=0A=0A
 
=0A=0A
 
=0A=0A
> With my proposal you can incremental= ly add newer=0Aextensions as the earlier boxes would simply ignore this ext= ended data block=0Athat carries the new stuff.
= =0A=0A
 
=0A=0A
Wr= ong. If the length is not correct then the packet is=0Alikely dropped. If t= he packet is not dropped then you are in an undefined area=0Aand can only h= ope for a "reasonable" behaviour. Exactly such an=0Aundefined area is what = I want to avoid. Nor is processing of the new packet=0Awhat you want in all= cases.
=0A=0A
 
=0A=0A
 
=0A=0A=
> If youre not comfortable with adding stuff after the=0ABF= D payload then we can always take up an Auth Type (say 9) which can then be= =0Aused to carry all the other interesting stuff.
=0A=0A
<= o:p> 
=0A=0A
what has this to do with auth?  This is what I name a "hack",=0Asorry. It's exactly my problem, we "wo= rk around" instead of=0Aaddressing a problem straight forward.
=0A=0A
(I'm not surprised you bring up auth as = this is an area=0Ayou heavily work on ;-)
=0A= =0A
 
=0A=0A
 
=0A=0A
Regards, Marc=
=0A=0A
 
=0A= =0A
 
=0A=0A
>= ;
=0A=0A
> Cheers, Manav
=0A=0A
>
= =0A=0A
>> -----Original Message-----
=0A=0A
>> From: Marc=0ABind= erberger [ma= ilto:marc@sniff.de]
=0A=0A
>> Sent: Monday, May 27, 2013 12:33 PM=
=0A=0A
>> To: Bhatia, Manav (Mana= v)
=0A=0A
>> Cc: Jeffrey Haas= ; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net= );
=0A=0A
>> rtg-bfd@ietf.org= ;=0AMarc Binderberger
=0A=0A
>> Subject: Re: The "version" topic (was:=0ARese= rved discriminators?)
=0A=0A
>&g= t;
=0A=0A
>> Hello Manav,
=0A=0A
>>
=0A=0A
>> all fine and good - but I really don't= =0Aunderstand this avoidance of a
=0A=0A
=
>> version change while we start looking for=0A"ways to extend= " that all
=0A=0A
>> have th= e one or other limit. What is the problem=0Aof thinking this
=0A=0A
>> straight forward: you have a cha= nge - forget=0A"substantial" - or even
=0A=0A<= /div>
>> a re-interpretation in the header, then it _is_=0Aa n= ew version.
=0A=0A
>>
=0A=0A
>> Programming-wise this is = clean, you have a=0Awell-defined indicator
=0A= =0A
>> that this packet needs a different treatment.=
=0A=0A
>> Nothing to conclude, no= t depending on IP header=0Alength - BFD per se
=0A=0A
>> is not IP related - and the right place is=0Ar= eally the BFD header
=0A=0A
>&g= t; itself when your idea is for the many BFD usages=0A(IP, IP-less).
=0A=0A
>>
<= div>=0A=0A
= >> The "backwards compatible" header I=0Aput i= n my last email was just the
=0A=0A
>> very few first fields. The rest may look very=0Adifferent. Even = when
=0A=0A
>> the rest of t= he header would have the same size=0Aof an v1 header but I
=0A=0A
>> interpret them differently, then t= hat's not v1=0Aanymore.
=0A=0A
>= ;>
=0A=0A
>> <= /font>
=0A=0A
>> Regards, Marc
=0A=0A
>>
=0A=0A=
>>
=0A=0A
>= ;>
=0A=0A
>> On 2013-05-2= 7, at 6:50 , Bhatia, Manav (Manav)=0Awrote:
=0A= =0A
>>
=0A=0A
&g= t;>> Alternatively, we can use the=0A"Authentication Present" bit
=0A=0A
>> in the header to carr= y this additional block.
=0A=0A
>= ;>>
=0A=0A
>>> Once= draft-ietf-bfd-generic-crypto-auth-04=0Abecomes a
=
=0A=0A
>> standard we will never consume any more bi= ts in=0Athe Auth Type
=0A=0A
>= ;> as this draft introduces a Key ID mechanism.=0AThis means that <= /o:p>
=0A=0A
>> Auth Type values beyond = 8 are available to be=0Aused for other
=0A=0A<= /div>
>> mechanisms.
=0A=0A
<= div style=3D"margin: 0in 0in 0pt;" class=3D"MsoPlainText">>>>
=0A=0A
>>= > We could for instance define value 8 meaning=0Aa BFD data <= /font>
=0A=0A
>> block. This can then be TLV en= coded.
=0A=0A
>>>
=0A=0A
>>> This is again an exam= ple of how BFD can be=0Aextended while
=0A=0A<= /div>
>> remaining completely backward compatible --=0Awithout= bumping
=0A=0A
>> the versi= on of BFD.
=0A=0A
>>>
=0A=0A
>>> Cheers, Manav=
=0A=0A
>>> <= /div>
=0A=0A
>>>> -----Original Message-----
=0A=0A
>>= >> From: rtg-bfd-bounces@ietf.org
=0A= =0A
>>>> [mailto:rtg-bfd-bounces@ietf.org= ] On=0ABehalf Of Bhatia,
=0A=0A
>> Manav (Manav)
=0A= =0A
>>>> Sent: Monday, May 27, 2013 10:07 AM
=0A=0A
>>>> To: Marc Binderbe= rger; Jeffrey Haas;=0ANobo Akiya (nobo)
=0A=0A<= /div>
>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org
=0A=0A
= >>>> Subject: RE: The "version"=0Atopic (was: Reserved discrimi= nators?)
=0A=0A
>>>>
=0A=0A
>>>> Hi Marc,
=0A=0A
>>>>
=0A=0A
>>>> We usually do a version = change when=0Athere is a very very
=0A=0A
>> substantial
=0A=0A
>>>> upgrade to the protocol - a kind that's=0Ausually non ba= ckward
=0A=0A
>>>> com= patible.
=0A=0A
>>>>
=0A=0A
>>>> If we really= want to introduce newer=0Afields to the packet
=0A=0A
>> while being
=0A= =0A
>>>> backward compatible then the best=0Aapproa= ch imo is this:
=0A=0A
>>>= >
=0A=0A
>>>> You s= tuff whatever additional information=0Ayou want in a
=0A=0A
>> special BFD
=0A=0A
>>>> data block immediately at the end of t= he=0ABFD packet. Don't include
=0A=0A
>>>> the length of this additional BFD block=0Ain the BFD h= eader.
=0A=0A
>> Instead,
=0A=0A
>>>> account for = this in the IPv4/IPv6 header=0Alength.
=0A=0A
>>>>
=0A=0A
>>>> =0A+----= -----------------+ --   &= nbsp;   
=0A=0A
>>>>  |=0AIP= Header     &nb= sp;     | ^&n= bsp;    
=0A=0A
>>>>  |= =0ALength =3D HL+X+Y   &n= bsp; | | Header Length
=0A=0A
>>>> =0A|       &n= bsp;            = ; | v    &nbs= p;          =
=0A=0A
>>>> =0A+---------------------+ --          =   =0A
=0A=0A
>= ;>>>  |=0ABFD  Header         | ^     
=0A=0A
>>>>  |=0ALength =3D X          | |      =
=0A=0A
>>>> =0A|.....................| | X   
<= div>=0A=0A
= >>>>&= nbsp;=0A|    =             &nb= sp;    | | &n= bsp;   
=0A=0A
>>>>  |=0ABFD=   Data           <= /span>|     
=0A=0A
>>>> =0A|           &nb= sp;         | v     
=0A=0A
>>>> =0A+---------------------+ --    
= =0A=0A
>>>> = ;=0A|    &nbs= p;            &= nbsp;   | ^
=0A=0A
>>>>  |=0ABFD D= ata Block      = | Y
=0A=0A
>>>><= span style=3D"mso-spacerun: yes;"> =0A|          &nbs= p;          | v
=0A=0A
>>>> =0A+---------------------+ --
=0A=0A
>>>>
=0A=0A
<= font face=3D"Calibri">>>>> How this additional BFD data block w= ill=0Abe used is beyond
=0A=0A
>= ;> the scope
=0A=0A
>>>= ;> of the discussion right now. You could=0Adefine that to be
=0A=0A
>> TLV encoded
=0A=0A
>>>> for ensuring easy extensib= ility.
=0A=0A
>>>>
=0A=0A
>>>> Implementation= s can either implicitly=0Afigure out the
=0A= =0A
>> presence of the
=0A= =0A
>>>> BFD data block by looking at the packet=0A= lengths in the
=0A=0A
>> hea= ders or can
=0A=0A
>>>>= ; explicitly be indicated in the BFD=0Aheader.
= =0A=0A
>>>>
=0A=0A
>>>> If people think it's a worthwhile idea=0Ato pursu= e then this can be
=0A=0A
>>= >> quickly drafted.
=0A=0A
&g= t;>>>
=0A=0A
>>>= > Cheers, Manav
=0A=0A
>>&= gt;>
=0A=0A
>>>>>= ; -----Original Message-----
=0A=0A
= >>>>> From: rtg-bfd-bounces@ietf.org
=0A=0A
>>>>> [mail= to:rtg-bfd-bounces@ietf.org] On=0ABehalf = Of Marc Binderberger
=0A=0A
>>= ;>>> Sent: Sunday, May 26, 2013 6:49 PM
=0A=0A
>>>>> To: Jeffrey Haas; Nobo Akiya (nob= o)
=0A=0A
>>>>> Cc: = Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org=
=0A=0A
>>>>> Subject: The = "version"=0Atopic (was: Reserved discriminators?)
=0A=0A
<= font face=3D"Calibri">>>>>>
=0A= =0A
>>>>> Hello everyone,
=0A=0A
>>>>>
= =0A=0A
>>>>> sorry for me delayed response.=
=0A=0A
>>>>> =
=0A=0A
>>>>> Taking a step bac= k. If we would=0Awrite RFC5880 today then we
= =0A=0A
>>>> probably
= =0A=0A
>>>>> would have reserved a small number= =0Aof discriminators, e.g.
=0A=0A
= >>>> the first 8
=0A=0A
>>>>> or 16 values. = ; But RFC5880 is since 3 years out, the
= =0A=0A
>>>> underlying draft
=0A=0A
>>>>> is even much older. The state= ment in=0Athe Spec is
=0A=0A
>= ;> effectively: dear
=0A=0A
>= ;>>>> implementor, beside the zero value=0Ado what you like wit= h
=0A=0A
>>>> this valu= e. 
=
=0A=0A
>>>>> We cannot claim back parts of = the=0Anumber space without risking
=0A=0A
>>>>> problems.
=0A=0A
>>>>>
=0A=0A
=
>>>>> This is why I tend more and more to=0Ahave clea= n separation,
=0A=0A
>>>&g= t; be it a new
=0A=0A
>>>&= gt;> IP/UDP port like BFD-on-lags or be=0Ait a new version number. =
=0A=0A
>>>> The latter=
=0A=0A
>>>>> faces, I th= ink, largely a=0Apsychological problem :-)
=0A= =0A
>>>>>
=0A=0A
>>>>> Independent if Nobo and me can=0Aconvince th= is audience about the
=0A=0A
>= ;>>>> redundancy concept we propose -=0Aworking on it - I do se= e more
=0A=0A
>>>>> = (private) ideas that cover BFD=0Asessions in a general sense,
=0A=0A
>>>> i.e. cover
=0A=0A
>>>>> the various RFCs, si= ngle-,=0Amulti-hop, with/withou label and
=0A= =0A
>>>> so on.&= nbsp;=0AIn
=0A=0A
>>&g= t;>> all cases I see people spending time=0Ato "fiddle about the=
=0A=0A
>>>> bits" of the
=0A=0A
>>>>> BFD v1 an= d the IP header. Smart=0Astuff but somehow crazy how
=0A=0A
>>>> wicked the
=0A=0A
>>>>> new definitions become, not t= o=0Amention the difficulties for
=0A=0A
<= div style=3D"margin: 0in 0in 0pt;" class=3D"MsoPlainText">>>>>> implementations and for interop.
=0A=0A
>>>>>
=0A=0A
>>>>>
=0A=0A
>>>>> Yes, we have a limited number of= =0Aversions available. Let me throw
=0A=0A
>>>>> this idea at the BFD audience: the=0Abase v2 = header would look like
=0A=0A
>= ;>>>> this:
=0A=0A
>= ;>>>>
=0A=0A
>>&= gt;>>  =0A0       &nbs= p;           1       &n= bsp;           2       =             3=
=0A=0A
>>>>>  =0A0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=0A=0A
>>>>>
=0A=0A
=
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
=0A=0A
>>>>><= span style=3D"mso-spacerun: yes;"> =0A|0 1 0| Subtype |   TBD, depending=0Aon Subtype<= span style=3D"mso-spacerun: yes;">   |   
=0A= =0A
>> Length &nb= sp;  =0A|
=0A=0A
&= gt;>>>>
=0A=0A
>>= ;=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /o:p>
=0A=0A
>>>>> =0A|            &n= bsp;          My Discri= minator     &nb= sp;         
=0A=0A
>>        |=
=0A=0A
>>>>>
=
=0A=0A
>>=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
=0A=0A
&g= t;>>>> =0A|       &nb= sp;            =   Your=0ADiscriminator =             &nb= sp;
=0A=0A
>>        |
=0A=0A
>>>>>
=0A=0A
>>=0A+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A=0A
>>>>>&= nbsp;=0A| ...   &n= bsp;            = ;            &n= bsp;            = ;         =0A
=0A=0A
>>        |=
=0A=0A
>>>>>
=
=0A=0A
>>>>>
= =0A=0A
>>>>> The subtype (the former Diag field)= =0Awould allow for 32 new
=0A=0A
&= gt;>>>> definitions. Actually I do not hope=0Amyself we define = so many
=0A=0A
>>>>>= ; variations ;-) but it opens up room=0Athat we do not have with the <= /o:p>
=0A=0A
>>>>> version fiel= d alone.
=0A=0A
>>>>>= ;
=0A=0A
>>>>> To e= mphasize: defining a v2 header=0Adoes not mean v1 is
=0A=0A
>> obsolete. BFD
=0A=0A
<= font face=3D"Calibri">>>>>> v1 works great, I'm not trying t= o=0Areplace it and whenever
=0A=0A
>> it can be
=0A=0A
>>= ;>>> used it must be used.
=0A=0A
>>>>>
=0A=0A
>>>>> For the other fields above, just=0Aquickly my though= ts (if
=0A=0A
>> we want to =
=0A=0A
>>>>> dive d= eeper into this I better write=0Aa draft to discuss):
=0A=0A
>>>>>
=0A=0A
>>>>> - length field remains in it's=0Ap= osition, for ease of
=0A=0A
>&g= t; implementation
=0A=0A
>>&g= t;>>
=0A=0A
>>>>= > - of course I keep the discriminator=0Aconcept - or it
=0A=0A
>> wouldn't be BFD
=0A=0A
>>>>> anymore ;-) and I keep = them again at=0Athe same position
=0A=0A
=
>> (the coders
=0A=0A
>>>>> of NP, FPGA etc never have enough=0Acycles or gates. = And
=0A=0A
>> these fields <= o:p>
=0A=0A
>>>>> are use= d "in hardware")
=0A=0A
>>>= ;>>
=0A=0A
>>>>&= gt; - not obvious here but I would=0Adefine a relatively strict =
=0A=0A
>> upper size =
=0A=0A
>>>>> limit. I'm not proposing= a generic=0ATLV format, based on the
=0A=0A
>>>>> difficulties I know about=0Aimplementing = really fast I/O it
=0A=0A
>>= is better
=0A=0A
>>>>= > to have fixed formats, IMHO.
=0A=0A
<= div style=3D"margin: 0in 0in 0pt;" class=3D"MsoPlainText">>>>>>
=0A=0A
= >>>>>
=0A=0A
>&g= t;>>> Feedback is very welcome. And yes, I=0Ahave mixed emotions <= o:p>
=0A=0A
>> myself to
=0A=0A
>>>>> let the genie= out of the bottle :-)
=0A=0A
>= ;>>>>
=0A=0A
>>&= gt;>>
=0A=0A
>>>>= ;> Thanks & Regards,
=0A=0A
= >>>>> Marc
=0A=0A
&g= t;>>>>
=0A=0A
>>= >>>
=0A=0A
>>>&g= t;>
=0A=0A
>>>>>= On 2013-05-17, at 17:35 , Nobo Akiya=0A(nobo) wrote:
=0A=0A
>>>>>
=0A=0A
>>>>>> Hello Jeff, et al,<= /font>
=0A=0A
>>>>>>
=0A=0A
>>>>>>> But, if the = reserved value=0Awas used *only* for the context
=0A=0A
>>>>> of telling
=0A=0A
>>>>>>> the remote side "this= =0Ais your redundant connection", and some
=0A= =0A
>>>>>>> reserved value was used in=0AD= own state for Your
=0A=0A
>>&= gt;>> Discriminator to help
=0A=0A
<= div style=3D"margin: 0in 0in 0pt;" class=3D"MsoPlainText">>>>>>>> with de-multiplexing (e.g.
=0A=0A
>>>>>>> 1 or 0xfffff= fff), that would=0Abe sufficient.
=0A=0A
<= div style=3D"margin: 0in 0in 0pt;" class=3D"MsoPlainText">>>>>>>
=0A=0A
>>>>>> Correct, that was my thoughts.=0ALet's say res= erved value
=0A=0A
>>>>= > one(1) was used for shadow session=0Abootstrapping purpose.
=0A=0A
>>>>> Value one(1) of = shadow is equivalent=0Aof value zero(0) of
=0A= =0A
>> primary. If
=0A=0A
>>>>> "your discriminator =3D=3D 1"=0Ais received = on a node which understands
=0A=0A
>>>>> this, then it is to map to shadow=0Asession.
=0A=0A
>>>>> De-multiplex = success.
=0A=0A
>>>>>= ;>
=0A=0A
>>>>>&= gt; - Benefit of the redundancy=0Aconcept is seen more on=
=0A=0A
>>>>> distributed systems or a= system=0Ahaving at least two cards
=0A=0A
>>>>> (ex: 2 route processor cards) which=0ABFD can = run actively.
=0A=0A
>>>&g= t;>> - Benefit of the redundancy=0Aconcept is also seen more on<= /o:p>
=0A=0A
>>>>> those BFD se= ssions which aren't tied=0Ato specific physical
=0A=0A
>> interfaces
=0A= =0A
>>>>> (ex: multihop, logical/virtual=0Ainter= faces).
=0A=0A
>>>>>= > - Redundancy concept is=0Aapplicable to both SW and HW based BFD.=
=0A=0A
>>>>>>
=0A=0A
>>>>>> Scope of = use case has=0Alimitations, in terms of system
= =0A=0A
>>>>> architecture as well as BFD type,= =0Abut for those that this applies
=0A=0A
>>>>> to, I still do see great benefits.<= /font>
=0A=0A
>>>>>>
=0A=0A
>>>>>>> We still hav= e a possibility=0Aof colliding with existing
= =0A=0A
>>>> sessions if
=0A=0A
>>>>>>> the remote side makes use = of=0Athe reserved value.  Bu= mping
=0A=0A
>>>>> t= he version
=0A=0A
>>>>&= gt;>> number is an obvious fix but=0Aif we're going to that extent
=0A=0A
>>>>> we need t= o
=0A=0A
>>>>>>&g= t; think more carefully about=0Athe full work we'd want under
=0A=0A
>>>>> such a rev.
=0A=0A
>>>>>>
=0A=0A
>>>>>> I still d= o not see any=0Aimplementations which cannot support
=0A=0A
>>>>> few more reserved discriminat= ors.=0ABut a node speaking to another
=0A=0A
>>>>> which doesn't support added reserved=0Adi= scriminator range can
=0A=0A
>= ;>>>> certainly cause undesired collision.=0AAnd I agree that b= umping the
=0A=0A
>>>>= > version number would solve this=0Aeasily.
= =0A=0A
>>>>>>
= =0A=0A
>>>>>> Regards,
=0A=0A
>>>>>> Nobo
=0A=0A
>>>>>>
=0A=0A
>>>>>
= =0A=0A
>>>>>
=0A=0A=
>>
=0A=0A
>= ;>
=0A=0A
 
=0A=0A
 
Regards,<= br>Prasad.
---1314897756-1538230658-1369656667=:17325-- From manav.bhatia@alcatel-lucent.com Mon May 27 05:17:48 2013 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 BC04021F8A6B for ; Mon, 27 May 2013 05:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmiliRvnhvZa for ; Mon, 27 May 2013 05:17:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4F15921F93BB for ; Mon, 27 May 2013 05:17:19 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4RCHBVZ022516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2013 07:17:12 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r4RCH701006110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 08:17:08 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 27 May 2013 08:17:06 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Mon, 27 May 2013 20:17:04 +0800 From: "Bhatia, Manav (Manav)" To: G Vengada Prasad , Marc Binderberger Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWtNEWNAQjdgdjUGntjfJd/sEA5kY8UIQ Date: Mon, 27 May 2013 12:17:03 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C30353B4@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <1369656667.17325.YahooMailNeo@web162502.mail.bf1.yahoo.com> In-Reply-To: <1369656667.17325.YahooMailNeo@web162502.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: multipart/alternative; boundary="_000_20211F91F544D247976D84C5D778A4C30353B4SG70YWXCHMBA05zap_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Mon, 27 May 2013 07:16:07 -0700 Cc: Jeff Haas , "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, 27 May 2013 12:17:48 -0000 --_000_20211F91F544D247976D84C5D778A4C30353B4SG70YWXCHMBA05zap_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Prasad, WHat i had meant when i had said that packets will get dropped is that spea= kers who only understand v1 will not be able to parse the v2 packet. Obviou= sly, v1 sessions will continue to work. Also, i was having this as a general discussion about how BFD could be exte= nded given that it has fixed fields -- I did not have any specific draft in= my mind. Cheers, Manav ________________________________ From: G Vengada Prasad [mailto:gvprasad@yahoo.com] Sent: Monday, May 27, 2013 5:41 PM To: Marc Binderberger; Bhatia, Manav (Manav) Cc: Jeff Haas; rtg-bfd@ietf.org Subject: Re: The "version" topic (was: Reserved discriminators?) Hello all, One more point that may be worth clarifying here, >> All currently deployed routers will drop these packets as they would con= sider the version field as invalid. >Exactly that is the beauty, yes. If someone does not implement a new featu= re then please please drop the packet. My understanding is that there would be _no_ impact to the v1 sessions due = ot the mechanism(s) proposed in the draft - they would continue to work. In= other words if device-A supporting (v1 and) v2 type sessions and device-B = supporting v1-only were to interop, the common minimum i.e. v1 BFD sessions= would continue to work as before. device-A may keep trying (forever?) to e= stablish v2 sessions but not get to Up state for v2 while v1 continues to w= ork as before. Hence there would be no loss of v1 BFD functionality. This a= pplies for any type of BFD session (Single-hop, multi-hop, MPLS label based= , VCCV etc). Marc/ Nobo, Please correct me if my understanding is inconsistent with the draft. Thanks Prasad Hello Manav, > Backward incompatibility is HUGE issue that's why I talk about a version increase - not that the incompatibility m= ust be automatically a huge issue - to cleanly separate things. > (especially since BFD is usually done in HW)! :) I have hardware implementations in mind as well. Exactly because you are po= tentially less flexible in "hacking something in" it's important to separat= e things. Besides: "usually" ... then we would see more really fast BFD implementatio= ns out there, something that just started really. No, 50msec interval is no= t really fast ;-) > The BFD version 2 would only work when all participating devices have upg= raded to the new version. There is still this misunderstanding that v2 means we deprecate v1. We don'= t. What we talk are new features. They will of course only work in an inter= operable way when all participants in the setup support it - this has nothi= ng to do with version numbers. > All currently deployed routers will drop these packets as they would cons= ider the version field as invalid. Exactly that is the beauty, yes. If someone does not implement a new featur= e then please please drop the packet. > So, there must be a very sound reason for taking such a drastic and a rad= ical step - I don't think we have heard any that warrants such a significan= t change! Manav, there is no reason naming this "drastic", "radical" or whatever. Whe= n we introduce a new UDP port then equipment not supporting it is dropping = these packets too as no one is listening to it. Haven't seen any such comme= nts in such a case (and yes, when you can do it with a new UDP port plus v1= then we go with v1. Not all cases can be covered this way though) > With my proposal you can incrementally add newer extensions as the earlie= r boxes would simply ignore this extended data block that carries the new s= tuff. Wrong. If the length is not correct then the packet is likely dropped. If t= he packet is not dropped then you are in an undefined area and can only hop= e for a "reasonable" behaviour. Exactly such an undefined area is what I wa= nt to avoid. Nor is processing of the new packet what you want in all cases= . > If youre not comfortable with adding stuff after the BFD payload then we = can always take up an Auth Type (say 9) which can then be used to carry all= the other interesting stuff. what has this to do with auth? This is what I name a "hack", sorry. It's e= xactly my problem, we "work around" instead of addressing a problem straigh= t forward. (I'm not surprised you bring up auth as this is an area you heavily work on= ;-) Regards, Marc > > Cheers, Manav > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, May 27, 2013 12:33 PM >> To: Bhatia, Manav (Manav) >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); >> rtg-bfd@ietf.org; Marc Binderberger >> Subject: Re: The "version" topic (was: Reserved discriminators?) >> >> Hello Manav, >> >> all fine and good - but I really don't understand this avoidance of a >> version change while we start looking for "ways to extend" that all >> have the one or other limit. What is the problem of thinking this >> straight forward: you have a change - forget "substantial" - or even >> a re-interpretation in the header, then it _is_ a new version. >> >> Programming-wise this is clean, you have a well-defined indicator >> that this packet needs a different treatment. >> Nothing to conclude, not depending on IP header length - BFD per se >> is not IP related - and the right place is really the BFD header >> itself when your idea is for the many BFD usages (IP, IP-less). >> >> The "backwards compatible" header I put in my last email was just the >> very few first fields. The rest may look very different. Even when >> the rest of the header would have the same size of an v1 header but I >> interpret them differently, then that's not v1 anymore. >> >> >> Regards, Marc >> >> >> >> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: >> >>> Alternatively, we can use the "Authentication Present" bit >> in the header to carry this additional block. >>> >>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a >> standard we will never consume any more bits in the Auth Type >> as this draft introduces a Key ID mechanism. This means that >> Auth Type values beyond 8 are available to be used for other >> mechanisms. >>> >>> We could for instance define value 8 meaning a BFD data >> block. This can then be TLV encoded. >>> >>> This is again an example of how BFD can be extended while >> remaining completely backward compatible -- without bumping >> the version of BFD. >>> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org >>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, >> Manav (Manav) >>>> Sent: Monday, May 27, 2013 10:07 AM >>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) >>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@i= etf.org >>>> Subject: RE: The "version" topic (was: Reserved discriminators?) >>>> >>>> Hi Marc, >>>> >>>> We usually do a version change when there is a very very >> substantial >>>> upgrade to the protocol - a kind that's usually non backward >>>> compatible. >>>> >>>> If we really want to introduce newer fields to the packet >> while being >>>> backward compatible then the best approach imo is this: >>>> >>>> You stuff whatever additional information you want in a >> special BFD >>>> data block immediately at the end of the BFD packet. Don't include >>>> the length of this additional BFD block in the BFD header. >> Instead, >>>> account for this in the IPv4/IPv6 header length. >>>> >>>> +---------------------+ -- >>>> | IP Header | ^ >>>> | Length =3D HL+X+Y | | Header Length >>>> | | v >>>> +---------------------+ -- >>>> | BFD Header | ^ >>>> | Length =3D X | | >>>> |.....................| | X >>>> | | | >>>> | BFD Data | >>>> | | v >>>> +---------------------+ -- >>>> | | ^ >>>> | BFD Data Block | Y >>>> | | v >>>> +---------------------+ -- >>>> >>>> How this additional BFD data block will be used is beyond >> the scope >>>> of the discussion right now. You could define that to be >> TLV encoded >>>> for ensuring easy extensibility. >>>> >>>> Implementations can either implicitly figure out the >> presence of the >>>> BFD data block by looking at the packet lengths in the >> headers or can >>>> explicitly be indicated in the BFD header. >>>> >>>> If people think it's a worthwhile idea to pursue then this can be >>>> quickly drafted. >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org >>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger >>>>> Sent: Sunday, May 26, 2013 6:49 PM >>>>> To: Jeffrey Haas; Nobo Akiya (nobo) >>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@= ietf.org >>>>> Subject: The "version" topic (was: Reserved discriminators?) >>>>> >>>>> Hello everyone, >>>>> >>>>> sorry for me delayed response. >>>>> >>>>> Taking a step back. If we would write RFC5880 today then we >>>> probably >>>>> would have reserved a small number of discriminators, e.g. >>>> the first 8 >>>>> or 16 values. But RFC5880 is since 3 years out, the >>>> underlying draft >>>>> is even much older. The statement in the Spec is >> effectively: dear >>>>> implementor, beside the zero value do what you like with >>>> this value. >>>>> We cannot claim back parts of the number space without risking >>>>> problems. >>>>> >>>>> This is why I tend more and more to have clean separation, >>>> be it a new >>>>> IP/UDP port like BFD-on-lags or be it a new version number. >>>> The latter >>>>> faces, I think, largely a psychological problem :-) >>>>> >>>>> Independent if Nobo and me can convince this audience about the >>>>> redundancy concept we propose - working on it - I do see more >>>>> (private) ideas that cover BFD sessions in a general sense, >>>> i.e. cover >>>>> the various RFCs, single-, multi-hop, with/withou label and >>>> so on. In >>>>> all cases I see people spending time to "fiddle about the >>>> bits" of the >>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how >>>> wicked the >>>>> new definitions become, not to mention the difficulties for >>>>> implementations and for interop. >>>>> >>>>> >>>>> Yes, we have a limited number of versions available. Let me throw >>>>> this idea at the BFD audience: the base v2 header would look like >>>>> this: >>>>> >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0 1 0| Subtype | TBD, depending on Subtype | >> Length | >>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | My Discriminator >> | >>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Your Discriminator >> | >>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | ... >> | >>>>> >>>>> >>>>> The subtype (the former Diag field) would allow for 32 new >>>>> definitions. Actually I do not hope myself we define so many >>>>> variations ;-) but it opens up room that we do not have with the >>>>> version field alone. >>>>> >>>>> To emphasize: defining a v2 header does not mean v1 is >> obsolete. BFD >>>>> v1 works great, I'm not trying to replace it and whenever >> it can be >>>>> used it must be used. >>>>> >>>>> For the other fields above, just quickly my thoughts (if >> we want to >>>>> dive deeper into this I better write a draft to discuss): >>>>> >>>>> - length field remains in it's position, for ease of >> implementation >>>>> >>>>> - of course I keep the discriminator concept - or it >> wouldn't be BFD >>>>> anymore ;-) and I keep them again at the same position >> (the coders >>>>> of NP, FPGA etc never have enough cycles or gates. And >> these fields >>>>> are used "in hardware") >>>>> >>>>> - not obvious here but I would define a relatively strict >> upper size >>>>> limit. I'm not proposing a generic TLV format, based on the >>>>> difficulties I know about implementing really fast I/O it >> is better >>>>> to have fixed formats, IMHO. >>>>> >>>>> >>>>> Feedback is very welcome. And yes, I have mixed emotions >> myself to >>>>> let the genie out of the bottle :-) >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Marc >>>>> >>>>> >>>>> >>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: >>>>> >>>>>> Hello Jeff, et al, >>>>>> >>>>>>> But, if the reserved value was used *only* for the context >>>>> of telling >>>>>>> the remote side "this is your redundant connection", and some >>>>>>> reserved value was used in Down state for Your >>>>> Discriminator to help >>>>>>> with de-multiplexing (e.g. >>>>>>> 1 or 0xffffffff), that would be sufficient. >>>>>> >>>>>> Correct, that was my thoughts. Let's say reserved value >>>>> one(1) was used for shadow session bootstrapping purpose. >>>>> Value one(1) of shadow is equivalent of value zero(0) of >> primary. If >>>>> "your discriminator =3D=3D 1" is received on a node which understands >>>>> this, then it is to map to shadow session. >>>>> De-multiplex success. >>>>>> >>>>>> - Benefit of the redundancy concept is seen more on >>>>> distributed systems or a system having at least two cards >>>>> (ex: 2 route processor cards) which BFD can run actively. >>>>>> - Benefit of the redundancy concept is also seen more on >>>>> those BFD sessions which aren't tied to specific physical >> interfaces >>>>> (ex: multihop, logical/virtual interfaces). >>>>>> - Redundancy concept is applicable to both SW and HW based BFD. >>>>>> >>>>>> Scope of use case has limitations, in terms of system >>>>> architecture as well as BFD type, but for those that this applies >>>>> to, I still do see great benefits. >>>>>> >>>>>>> We still have a possibility of colliding with existing >>>> sessions if >>>>>>> the remote side makes use of the reserved value. Bumping >>>>> the version >>>>>>> number is an obvious fix but if we're going to that extent >>>>> we need to >>>>>>> think more carefully about the full work we'd want under >>>>> such a rev. >>>>>> >>>>>> I still do not see any implementations which cannot support >>>>> few more reserved discriminators. But a node speaking to another >>>>> which doesn't support added reserved discriminator range can >>>>> certainly cause undesired collision. And I agree that bumping the >>>>> version number would solve this easily. >>>>>> >>>>>> Regards, >>>>>> Nobo >>>>>> >>>>> >>>>> >> >> Regards, Prasad. --_000_20211F91F544D247976D84C5D778A4C30353B4SG70YWXCHMBA05zap_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Prasad,
 
WHat i had meant when i had said = that packets will get dropped is that speakers who only understand v1 will = not be able to parse the v2 packet. Obviously, v1 sessions will continue to work.
 
Also, i was having this as a gene= ral discussion about how BFD could be extended given that it has fixed fiel= ds -- I did not have any specific draft in my mind.
 
Cheers, Manav

From: G Vengada Prasad [mailto:gvpr= asad@yahoo.com]
Sent: Monday, May 27, 2013 5:41 PM
To: Marc Binderberger; Bhatia, Manav (Manav)
Cc: Jeff Haas; rtg-bfd@ietf.org
Subject: Re: The "version" topic (was: Reserved discrimina= tors?)

Hello all,
One more point that may be worth clarifying here,
 
>> All currently deployed routers will dr= op these packets as they would consider the version field as invalid.<= /o:p>
>Exactly that is the beauty, yes. If someone= does not implement a new feature then please please drop the packet.
My understanding is that there would be _no_ impact to the v= 1 sessions due ot the mechanism(s) proposed in the draft - they would = continue to work. In other words if device-A supporting (v1 and) v2 ty= pe sessions and device-B supporting v1-only were to interop, the common minimum i.e. v1 BFD sessions would continue to work as= before. device-A may keep trying (forever?) to establish v2 sessions but n= ot get to Up state for v2 while v1 continues to work as before. Hence there= would be no loss of v1 BFD functionality. This applies for any type of BFD session (Single-hop, multi-hop, MPLS= label based, VCCV etc).
 
Marc/ Nobo,
 Please correct me if my understanding is inconsistent with the d= raft.
 
Thanks
Prasad
 
Hello Manav,
 
> Backward incompatibility is HUGE issue
 
that's why I talk about a version increase - not that the incompatibi= lity must be automatically a huge issue - to cleanly separate things.<= /o:p>
 
> (especially since BFD is usually done in HW)! :)
 
I have hardware implementations in mind as well. Exactly because you = are potentially less flexible in "hacking something in" it's impo= rtant to separate things.
 
Besides: "usually" ... then we would see more really fast B= FD implementations out there, something that just started really. No, 50mse= c interval is not really fast ;-)
 
 
> The BFD version 2 would only work when all participating devices= have upgraded to the new version.
 
There is still this misunderstanding that v2 means we deprecate v1. W= e don't. What we talk are new features. They will of course only work in an= interoperable way when all participants in the setup support it - this has nothing to do with version numbers.
 
 
> All currently deployed routers will drop these packets as they w= ould consider the version field as invalid.
 
Exactly that is the beauty, yes. If someone does not implement a new = feature then please please drop the packet.
 
 
> So, there must be a very sound reason for taking such a drastic = and a radical step - I don't think we have heard any that warrants such a s= ignificant change!
 
Manav, there is no reason naming this "drastic", "radi= cal" or whatever. When we introduce a new UDP port then equipment not = supporting it is dropping these packets too as no one is listening to it. Haven't seen any such comments in such a case (and yes, when you ca= n do it with a new UDP port plus v1 then we go with v1. Not all cases can b= e covered this way though)
 
 
> With my proposal you can incrementally add newer extensions as t= he earlier boxes would simply ignore this extended data block that carries = the new stuff.
 
Wrong. If the length is not correct then the packet is likely dropped= . If the packet is not dropped then you are in an undefined area and can on= ly hope for a "reasonable" behaviour. Exactly such an undefined area is what I want to avoid. Nor is processing = of the new packet what you want in all cases.
 
 
> If youre not comfortable with adding stuff after the BFD payload= then we can always take up an Auth Type (say 9) which can then be used to = carry all the other interesting stuff.
 
what has this to do with auth? = ; This is what I name a "hack", sorry. It's exactly my probl= em, we "work around" instead of addressing a problem straight for= ward.
(I'm not surprised you bring up auth as this is an area you heavily w= ork on ;-)
 
 
Regards, Marc
 
 
>
> Cheers, Manav
>
>> -----Original Message-----
>> From: Marc Binderberger [mailto:marc@sniff.de]
>> Sent: Monday, May 27, 2013 12:33 PM
>> To: Bhatia, Manav (Manav)
>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net);
>> rtg-bfd@ietf.org= ; Marc Binderberger
>> Subject: Re: The "version" topic (was: Reserved di= scriminators?)
>>
>> Hello Manav,
>>
>> all fine and good - but I really don't understand this avoid= ance of a
>> version change while we start looking for "ways to exte= nd" that all
>> have the one or other limit. What is the problem of thinking= this
>> straight forward: you have a change - forget "substanti= al" - or even
>> a re-interpretation in the header, then it _is_ a new versio= n.
>>
>> Programming-wise this is clean, you have a well-defined indi= cator
>> that this packet needs a different treatment.
>> Nothing to conclude, not depending on IP header length - BFD= per se
>> is not IP related - and the right place is really the BFD he= ader
>> itself when your idea is for the many BFD usages (IP, IP-les= s).
>>
>> The "backwards compatible" header I put in my last= email was just the
>> very few first fields. The rest may look very different. Eve= n when
>> the rest of the header would have the same size of an v1 hea= der but I
>> interpret them differently, then that's not v1 anymore.=
>>
>>
>> Regards, Marc
>>
>>
>>
>> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote:
>>
>>> Alternatively, we can use the "Authentication Prese= nt" bit
>> in the header to carry this additional block.
>>>
>>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a
>> standard we will never consume any more bits in the Auth Typ= e
>> as this draft introduces a Key ID mechanism. This means that
>> Auth Type values beyond 8 are available to be used for other
>> mechanisms.
>>>
>>> We could for instance define value 8 meaning a BFD data
>> block. This can then be TLV encoded.
>>>
>>> This is again an example of how BFD can be extended whil= e
>> remaining completely backward compatible -- without bumping
>> the version of BFD.
>>>
>>> Cheers, Manav
>>>
>>>> -----Original Message-----
>>>> From: r= tg-bfd-bounces@ietf.org
>>>> [= mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia,
>> Manav (Manav)
>>>> Sent: Monday, May 27, 2013 10:07 AM
>>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nob= o)
>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@i= etf.org
>>>> Subject: RE: The "version" topic (was: Res= erved discriminators?)
>>>>
>>>> Hi Marc,
>>>>
>>>> We usually do a version change when there is a very = very
>> substantial
>>>> upgrade to the protocol - a kind that's usually non = backward
>>>> compatible.
>>>>
>>>> If we really want to introduce newer fields to the p= acket
>> while being
>>>> backward compatible then the best approach imo is th= is:
>>>>
>>>> You stuff whatever additional information you want i= n a
>> special BFD
>>>> data block immediately at the end of the BFD packet.= Don't include
>>>> the length of this additional BFD block in the BFD h= eader.
>> Instead,
>>>> account for this in the IPv4/IPv6 header length.
>>>>
>>>>  +---------------------+ --=        
>>>>  | IP Header    = ;       | ^     
>>>>  | Length =3D HL+X+Y &= nbsp;   | | Header Length
>>>>  |     &nb= sp;            =    | v   =            
>>>>  +---------------------+ --=             
>>>>  | BFD  Header         | ^      =
>>>>  | Length =3D X   &n= bsp;      | |     
>>>>  |.....................| | X &= nbsp; 
>>>>  |     &nb= sp;            =    | |   =   
>>>>  | BFD  Data        &nbs= p;  |     
>>>>  |     &nb= sp;            =    | v   =   
>>>>  +---------------------+ --=     
>>>>  |     &nb= sp;            =    | ^
>>>>  | BFD Data Block   =    | Y
>>>>  |     &nb= sp;            =    | v
>>>>  +---------------------+ --
>>>>
>>>> How this additional BFD data block will be used is b= eyond
>> the scope
>>>> of the discussion right now. You could define that t= o be
>> TLV encoded
>>>> for ensuring easy extensibility.
>>>>
>>>> Implementations can either implicitly figure out the
>> presence of the
>>>> BFD data block by looking at the packet lengths in t= he
>> headers or can
>>>> explicitly be indicated in the BFD header.
>>>>
>>>> If people think it's a worthwhile idea to pursue the= n this can be
>>>> quickly drafted.
>>>>
>>>> Cheers, Manav
>>>>
>>>>> -----Original Message-----
>>>>> From: r= tg-bfd-bounces@ietf.org
>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger
>>>>> Sent: Sunday, May 26, 2013 6:49 PM
>>>>> To: Jeffrey Haas; Nobo Akiya (nobo)
>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@i= etf.org
>>>>> Subject: The "version" topic (was: Res= erved discriminators?)
>>>>>
>>>>> Hello everyone,
>>>>>
>>>>> sorry for me delayed response.=
>>>>>
>>>>> Taking a step back. If we would write RFC5880 to= day then we
>>>> probably
>>>>> would have reserved a small number of discrimina= tors, e.g.
>>>> the first 8
>>>>> or 16 values.&= nbsp; But RFC5880 is since 3 years out, the
>>>> underlying draft
>>>>> is even much older. The statement in the Spec is
>> effectively: dear
>>>>> implementor, beside the zero value do what you l= ike with
>>>> this value. 
>>>>> We cannot claim back parts of the number space w= ithout risking
>>>>> problems.
>>>>>
>>>>> This is why I tend more and more to have clean s= eparation,
>>>> be it a new
>>>>> IP/UDP port like BFD-on-lags or be it a new vers= ion number.
>>>> The latter
>>>>> faces, I think, largely a psychological problem = :-)
>>>>>
>>>>> Independent if Nobo and me can convince this aud= ience about the
>>>>> redundancy concept we propose - working on it - = I do see more
>>>>> (private) ideas that cover BFD sessions in a gen= eral sense,
>>>> i.e. cover
>>>>> the various RFCs, single-, multi-hop, with/witho= u label and
>>>> so on.  In
>>>>> all cases I see people spending time to "fi= ddle about the
>>>> bits" of the
>>>>> BFD v1 and the IP header. Smart stuff but someho= w crazy how
>>>> wicked the
>>>>> new definitions become, not to mention the diffi= culties for
>>>>> implementations and for interop.
>>>>>
>>>>>
>>>>> Yes, we have a limited number of versions availa= ble. Let me throw
>>>>> this idea at the BFD audience: the base v2 heade= r would look like
>>>>> this:
>>>>>
>>>>>   0     &nb= sp;            = 1     &n= bsp;            = ; 2     &nb= sp;            = 3
>>>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
>>>>>
>> +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+
>>>>>  |0 1 0| Subtype |   TBD, depending on Subtype   |   
>> Length   &n= bsp; |
>>>>>
>> +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+
>>>>>  |     &nb= sp;            =      My Discriminator           &n= bsp;   
>>    &nb= sp;   |
>>>>>
>> +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+
>>>>>  |     &nb= sp;            =     Your Discriminator            =   
>>    &nb= sp;   |
>>>>>
>> +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+
>>>>>  | ...     = ;            &n= bsp;            = ;            &n= bsp;       
>>    &nb= sp;   |
>>>>>
>>>>>
>>>>> The subtype (the former Diag field) would allow = for 32 new
>>>>> definitions. Actually I do not hope myself we de= fine so many
>>>>> variations ;-) but it opens up room that we do n= ot have with the
>>>>> version field alone.
>>>>>
>>>>> To emphasize: defining a v2 header does not mean= v1 is
>> obsolete. BFD
>>>>> v1 works great, I'm not trying to replace it and= whenever
>> it can be
>>>>> used it must be used.
>>>>>
>>>>> For the other fields above, just quickly my thou= ghts (if
>> we want to
>>>>> dive deeper into this I better write a draft to = discuss):
>>>>>
>>>>> - length field remains in it's position, for eas= e of
>> implementation
>>>>>
>>>>> - of course I keep the discriminator concept - o= r it
>> wouldn't be BFD
>>>>> anymore ;-) and I keep them again at the same po= sition
>> (the coders
>>>>> of NP, FPGA etc never have enough cycles or gate= s. And
>> these fields
>>>>> are used "in hardware")
>>>>>
>>>>> - not obvious here but I would define a relative= ly strict
>> upper size
>>>>> limit. I'm not proposing a generic TLV format, b= ased on the
>>>>> difficulties I know about implementing really fa= st I/O it
>> is better
>>>>> to have fixed formats, IMHO.
>>>>>
>>>>>
>>>>> Feedback is very welcome. And yes, I have mixed = emotions
>> myself to
>>>>> let the genie out of the bottle :-)
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Marc
>>>>>
>>>>>
>>>>>
>>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrot= e:
>>>>>
>>>>>> Hello Jeff, et al,
>>>>>>
>>>>>>> But, if the reserved value was used *onl= y* for the context
>>>>> of telling
>>>>>>> the remote side "this is your redun= dant connection", and some
>>>>>>> reserved value was used in Down state fo= r Your
>>>>> Discriminator to help
>>>>>>> with de-multiplexing (e.g.
>>>>>>> 1 or 0xffffffff), that would be sufficie= nt.
>>>>>>
>>>>>> Correct, that was my thoughts. Let's say res= erved value
>>>>> one(1) was used for shadow session bootstrapping= purpose.
>>>>> Value one(1) of shadow is equivalent of value ze= ro(0) of
>> primary. If
>>>>> "your discriminator =3D=3D 1" is recei= ved on a node which understands
>>>>> this, then it is to map to shadow session.<= /o:p>
>>>>> De-multiplex success.
>>>>>>
>>>>>> - Benefit of the redundancy concept is seen = more on
>>>>> distributed systems or a system having at least = two cards
>>>>> (ex: 2 route processor cards) which BFD can run = actively.
>>>>>> - Benefit of the redundancy concept is also = seen more on
>>>>> those BFD sessions which aren't tied to specific= physical
>> interfaces
>>>>> (ex: multihop, logical/virtual interfaces).=
>>>>>> - Redundancy concept is applicable to both S= W and HW based BFD.
>>>>>>
>>>>>> Scope of use case has limitations, in terms = of system
>>>>> architecture as well as BFD type, but for those = that this applies
>>>>> to, I still do see great benefits.
>>>>>>
>>>>>>> We still have a possibility of colliding= with existing
>>>> sessions if
>>>>>>> the remote side makes use of the reserve= d value.  Bumping
>>>>> the version
>>>>>>> number is an obvious fix but if we're go= ing to that extent
>>>>> we need to
>>>>>>> think more carefully about the full work= we'd want under
>>>>> such a rev.
>>>>>>
>>>>>> I still do not see any implementations which= cannot support
>>>>> few more reserved discriminators. But a node spe= aking to another
>>>>> which doesn't support added reserved discriminat= or range can
>>>>> certainly cause undesired collision. And I agree= that bumping the
>>>>> version number would solve this easily.
>>>>>>
>>>>>> Regards,
>>>>>> Nobo
>>>>>>
>>>>>
>>>>>
>>
>>
 
 
Regards,
Prasad.
--_000_20211F91F544D247976D84C5D778A4C30353B4SG70YWXCHMBA05zap_-- From marc@sniff.de Mon May 27 07:58:32 2013 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 467F221F9670 for ; Mon, 27 May 2013 07:58: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKBdch0ys8vG for ; Mon, 27 May 2013 07:58:31 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2E21F9377 for ; Mon, 27 May 2013 07:58:29 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A30FF2AA0F; Mon, 27 May 2013 14:58:24 +0000 (GMT) Subject: Re: The "version" topic (was: Reserved discriminators?) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Mon, 27 May 2013 16:58:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92DCCC04-A14C-46C5-9C64-AB3F0B389729@sniff.de> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: Nobo Akiya (nobo) X-Mailer: Apple Mail (2.1084) Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 14:58:32 -0000 Hello Nobo, sorry when I disagree to some extend. We have to address this in = parallel. Otherwise we end up with proposals for new usage that fall = back into "how to squeeze it into v1" - typically you will avoid = de-railing your feature discussion with the generic TLV/v2/whatever = extension discussion, for loss of focus on the feature (and loss of = progress, amount of time etc). I do agree that the extension discussion becomes more relevant once the = BFD audience sees more cases that won't fit easily into v1. That should = not stop us to prepare a good extension story. Doesn't mean this goes to = RFC anytime soon :-) Regards, Marc On 2013-05-27, at 16:10 , Nobo Akiya (nobo) wrote: > Hello Marc, Manav, >=20 > As much as I would like to see more pieces to play with, I honestly = don't see sufficient reasons to define such (generically speaking). >=20 > No matter how smart _how_ is, we will not get WG consensus without = people seeing great value(s). >=20 > We should go back to discussing _if_ we need to define such. >=20 > Regards, > Nobo >=20 > P.S. Your email is very interesting, I'll have to grab coffee and read = this couple of more times. >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, May 27, 2013 6:59 AM >> To: Bhatia, Manav (Manav) >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); = rtg- >> bfd@ietf.org >> Subject: Re: The "version" topic (was: Reserved discriminators?) >>=20 >> Hello Manav, >>=20 >> oh I'm sure for every proposal you will find someone who did this = already ;-) >>=20 >> The point would be really that BFD is not restricted to IP and you = would >> need to make sure the transport mechanism always has some length = field. >>=20 >> But I don't think we need this because ... >>=20 >>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD = data >> block", where BFD data block is TLV encoded. The first 8 type values = would >> indicate that a certain kind of authentication scheme is employed. = The >> other values would mean something else. >>=20 >>=20 >> ... this would be a much cleaner approach. As written in our private >> communication I still think that the version approach is a better = fit, at least >> for cases where you don't need or don't want all the v1 fields. Such = a >> proposal then describes how to not use such fields, where to deviate = from >> v1 ... practically you _do_ describe a new version (if you definition = of >> version isn't too strict) but with the risk of some implementations = stumbling >> as it's still a v1 packet. >>=20 >> Now the version approach is based on one assumption: that >> implementations do check the version field. Due to the BFD history = with v0 >> and v1 I have taken this for granted >>=20 >>=20 >> Anyway, I'm glad we have the discussion. And I hope for more opinions = :-) >>=20 >>=20 >> Best regards, >> Marc >>=20 >>=20 >>=20 >>=20 >> On 2013-05-27, at 10:00 , Bhatia, Manav (Manav) wrote: >>=20 >>> Hi Marc, >>>=20 >>> The "hack" that I have suggested already exists in OSPF!:) You can = read RFC >> 5613 for more sordid details. There are vendors that are shipping = code >> supporting this. I wager that if they were able to work around the IP = length >> issues in OSPF, then doing the same in BFD will not be too difficult! >>>=20 >>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD = data >> block", where BFD data block is TLV encoded. The first 8 type values = would >> indicate that a certain kind of authentication scheme is employed. = The >> other values would mean something else. >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>> Sent: Monday, May 27, 2013 1:03 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); >>>> rtg-bfd@ietf.org >>>> Subject: Re: The "version" topic (was: Reserved discriminators?) >>>>=20 >>>> Hello Manav, >>>>=20 >>>>> Backward incompatibility is HUGE issue >>>>=20 >>>> that's why I talk about a version increase - not that the >>>> incompatibility must be automatically a huge issue - to cleanly >>>> separate things. >>>>=20 >>>>> (especially since BFD is usually done in HW)! :) >>>>=20 >>>> I have hardware implementations in mind as well. Exactly because = you >>>> are potentially less flexible in "hacking something in" it's >>>> important to separate things. >>>>=20 >>>> Besides: "usually" ... then we would see more really fast BFD >>>> implementations out there, something that just started really. No, >>>> 50msec interval is not really fast ;-) >>>>=20 >>>>=20 >>>>> The BFD version 2 would only work when all participating >>>> devices have upgraded to the new version. >>>>=20 >>>> There is still this misunderstanding that v2 means we deprecate v1. >>>> We don't. What we talk are new features. They will of course only >>>> work in an interoperable way when all participants in the setup >>>> support it - this has nothing to do with version numbers. >>>>=20 >>>>=20 >>>>> All currently deployed routers will drop these packets as >>>> they would consider the version field as invalid. >>>>=20 >>>> Exactly that is the beauty, yes. If someone does not >>>> implement a new feature then please please drop the packet. >>>>=20 >>>>=20 >>>>> So, there must be a very sound reason for taking such a >>>> drastic and a radical step - I don't think we have heard any >>>> that warrants such a significant change! >>>>=20 >>>> Manav, there is no reason naming this "drastic", "radical" or >>>> whatever. When we introduce a new UDP port then equipment not >>>> supporting it is dropping these packets too as no one is >>>> listening to it. Haven't seen any such comments in such a >>>> case (and yes, when you can do it with a new UDP port plus v1 >>>> then we go with v1. Not all cases can be covered this way though) >>>>=20 >>>>=20 >>>>> With my proposal you can incrementally add newer extensions >>>> as the earlier boxes would simply ignore this extended data >>>> block that carries the new stuff. >>>>=20 >>>> Wrong. If the length is not correct then the packet is likely >>>> dropped. If the packet is not dropped then you are in an >>>> undefined area and can only hope for a "reasonable" >>>> behaviour. Exactly such an undefined area is what I want to >>>> avoid. Nor is processing of the new packet what you want in all = cases. >>>>=20 >>>>=20 >>>>> If youre not comfortable with adding stuff after the BFD >>>> payload then we can always take up an Auth Type (say 9) which >>>> can then be used to carry all the other interesting stuff. >>>>=20 >>>> what has this to do with auth? This is what I name a "hack", >>>> sorry. It's exactly my problem, we "work around" instead of >>>> addressing a problem straight forward. >>>> (I'm not surprised you bring up auth as this is an area you >>>> heavily work on ;-) >>>>=20 >>>>=20 >>>> Regards, Marc >>>>=20 >>>>=20 >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>> Sent: Monday, May 27, 2013 12:33 PM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas >>>> (jhaas@juniper.net); >>>>>> rtg-bfd@ietf.org; Marc Binderberger >>>>>> Subject: Re: The "version" topic (was: Reserved discriminators?) >>>>>>=20 >>>>>> Hello Manav, >>>>>>=20 >>>>>> all fine and good - but I really don't understand this >>>> avoidance of a >>>>>> version change while we start looking for "ways to extend" >>>> that all >>>>>> have the one or other limit. What is the problem of thinking this >>>>>> straight forward: you have a change - forget "substantial" >>>> - or even >>>>>> a re-interpretation in the header, then it _is_ a new version. >>>>>>=20 >>>>>> Programming-wise this is clean, you have a well-defined indicator >>>>>> that this packet needs a different treatment. >>>>>> Nothing to conclude, not depending on IP header length - >>>> BFD per se >>>>>> is not IP related - and the right place is really the BFD header >>>>>> itself when your idea is for the many BFD usages (IP, IP-less). >>>>>>=20 >>>>>> The "backwards compatible" header I put in my last email >>>> was just the >>>>>> very few first fields. The rest may look very different. Even = when >>>>>> the rest of the header would have the same size of an v1 >>>> header but I >>>>>> interpret them differently, then that's not v1 anymore. >>>>>>=20 >>>>>>=20 >>>>>> Regards, Marc >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: >>>>>>=20 >>>>>>> Alternatively, we can use the "Authentication Present" bit >>>>>> in the header to carry this additional block. >>>>>>>=20 >>>>>>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a >>>>>> standard we will never consume any more bits in the Auth Type >>>>>> as this draft introduces a Key ID mechanism. This means that >>>>>> Auth Type values beyond 8 are available to be used for other >>>>>> mechanisms. >>>>>>>=20 >>>>>>> We could for instance define value 8 meaning a BFD data >>>>>> block. This can then be TLV encoded. >>>>>>>=20 >>>>>>> This is again an example of how BFD can be extended while >>>>>> remaining completely backward compatible -- without bumping >>>>>> the version of BFD. >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, >>>>>> Manav (Manav) >>>>>>>> Sent: Monday, May 27, 2013 10:07 AM >>>>>>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) >>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>>>>>> Subject: RE: The "version" topic (was: Reserved = discriminators?) >>>>>>>>=20 >>>>>>>> Hi Marc, >>>>>>>>=20 >>>>>>>> We usually do a version change when there is a very very >>>>>> substantial >>>>>>>> upgrade to the protocol - a kind that's usually non backward >>>>>>>> compatible. >>>>>>>>=20 >>>>>>>> If we really want to introduce newer fields to the packet >>>>>> while being >>>>>>>> backward compatible then the best approach imo is this: >>>>>>>>=20 >>>>>>>> You stuff whatever additional information you want in a >>>>>> special BFD >>>>>>>> data block immediately at the end of the BFD packet. >>>> Don't include >>>>>>>> the length of this additional BFD block in the BFD header. >>>>>> Instead, >>>>>>>> account for this in the IPv4/IPv6 header length. >>>>>>>>=20 >>>>>>>> +---------------------+ -- >>>>>>>> | IP Header | ^ >>>>>>>> | Length =3D HL+X+Y | | Header Length >>>>>>>> | | v >>>>>>>> +---------------------+ -- >>>>>>>> | BFD Header | ^ >>>>>>>> | Length =3D X | | >>>>>>>> |.....................| | X >>>>>>>> | | | >>>>>>>> | BFD Data | >>>>>>>> | | v >>>>>>>> +---------------------+ -- >>>>>>>> | | ^ >>>>>>>> | BFD Data Block | Y >>>>>>>> | | v >>>>>>>> +---------------------+ -- >>>>>>>>=20 >>>>>>>> How this additional BFD data block will be used is beyond >>>>>> the scope >>>>>>>> of the discussion right now. You could define that to be >>>>>> TLV encoded >>>>>>>> for ensuring easy extensibility. >>>>>>>>=20 >>>>>>>> Implementations can either implicitly figure out the >>>>>> presence of the >>>>>>>> BFD data block by looking at the packet lengths in the >>>>>> headers or can >>>>>>>> explicitly be indicated in the BFD header. >>>>>>>>=20 >>>>>>>> If people think it's a worthwhile idea to pursue then >>>> this can be >>>>>>>> quickly drafted. >>>>>>>>=20 >>>>>>>> Cheers, Manav >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc = Binderberger >>>>>>>>> Sent: Sunday, May 26, 2013 6:49 PM >>>>>>>>> To: Jeffrey Haas; Nobo Akiya (nobo) >>>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>>>>>>> Subject: The "version" topic (was: Reserved discriminators?) >>>>>>>>>=20 >>>>>>>>> Hello everyone, >>>>>>>>>=20 >>>>>>>>> sorry for me delayed response. >>>>>>>>>=20 >>>>>>>>> Taking a step back. If we would write RFC5880 today then we >>>>>>>> probably >>>>>>>>> would have reserved a small number of discriminators, e.g. >>>>>>>> the first 8 >>>>>>>>> or 16 values. But RFC5880 is since 3 years out, the >>>>>>>> underlying draft >>>>>>>>> is even much older. The statement in the Spec is >>>>>> effectively: dear >>>>>>>>> implementor, beside the zero value do what you like with >>>>>>>> this value. >>>>>>>>> We cannot claim back parts of the number space without risking >>>>>>>>> problems. >>>>>>>>>=20 >>>>>>>>> This is why I tend more and more to have clean separation, >>>>>>>> be it a new >>>>>>>>> IP/UDP port like BFD-on-lags or be it a new version number. >>>>>>>> The latter >>>>>>>>> faces, I think, largely a psychological problem :-) >>>>>>>>>=20 >>>>>>>>> Independent if Nobo and me can convince this audience about = the >>>>>>>>> redundancy concept we propose - working on it - I do see more >>>>>>>>> (private) ideas that cover BFD sessions in a general sense, >>>>>>>> i.e. cover >>>>>>>>> the various RFCs, single-, multi-hop, with/withou label and >>>>>>>> so on. In >>>>>>>>> all cases I see people spending time to "fiddle about the >>>>>>>> bits" of the >>>>>>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how >>>>>>>> wicked the >>>>>>>>> new definitions become, not to mention the difficulties for >>>>>>>>> implementations and for interop. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Yes, we have a limited number of versions available. >>>> Let me throw >>>>>>>>> this idea at the BFD audience: the base v2 header would >>>> look like >>>>>>>>> this: >>>>>>>>>=20 >>>>>>>>> 0 1 2 3 >>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >>>> 7 8 9 0 1 >>>>>>>>>=20 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>> |0 1 0| Subtype | TBD, depending on Subtype | >>>>>> Length | >>>>>>>>>=20 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>> | My Discriminator >>>>>> | >>>>>>>>>=20 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>> | Your Discriminator >>>>>> | >>>>>>>>>=20 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>> | ... >>>>>> | >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The subtype (the former Diag field) would allow for 32 new >>>>>>>>> definitions. Actually I do not hope myself we define so many >>>>>>>>> variations ;-) but it opens up room that we do not have >>>> with the >>>>>>>>> version field alone. >>>>>>>>>=20 >>>>>>>>> To emphasize: defining a v2 header does not mean v1 is >>>>>> obsolete. BFD >>>>>>>>> v1 works great, I'm not trying to replace it and whenever >>>>>> it can be >>>>>>>>> used it must be used. >>>>>>>>>=20 >>>>>>>>> For the other fields above, just quickly my thoughts (if >>>>>> we want to >>>>>>>>> dive deeper into this I better write a draft to discuss): >>>>>>>>>=20 >>>>>>>>> - length field remains in it's position, for ease of >>>>>> implementation >>>>>>>>>=20 >>>>>>>>> - of course I keep the discriminator concept - or it >>>>>> wouldn't be BFD >>>>>>>>> anymore ;-) and I keep them again at the same position >>>>>> (the coders >>>>>>>>> of NP, FPGA etc never have enough cycles or gates. And >>>>>> these fields >>>>>>>>> are used "in hardware") >>>>>>>>>=20 >>>>>>>>> - not obvious here but I would define a relatively strict >>>>>> upper size >>>>>>>>> limit. I'm not proposing a generic TLV format, based on the >>>>>>>>> difficulties I know about implementing really fast I/O it >>>>>> is better >>>>>>>>> to have fixed formats, IMHO. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Feedback is very welcome. And yes, I have mixed emotions >>>>>> myself to >>>>>>>>> let the genie out of the bottle :-) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks & Regards, >>>>>>>>> Marc >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: >>>>>>>>>=20 >>>>>>>>>> Hello Jeff, et al, >>>>>>>>>>=20 >>>>>>>>>>> But, if the reserved value was used *only* for the context >>>>>>>>> of telling >>>>>>>>>>> the remote side "this is your redundant connection", and = some >>>>>>>>>>> reserved value was used in Down state for Your >>>>>>>>> Discriminator to help >>>>>>>>>>> with de-multiplexing (e.g. >>>>>>>>>>> 1 or 0xffffffff), that would be sufficient. >>>>>>>>>>=20 >>>>>>>>>> Correct, that was my thoughts. Let's say reserved value >>>>>>>>> one(1) was used for shadow session bootstrapping purpose. >>>>>>>>> Value one(1) of shadow is equivalent of value zero(0) of >>>>>> primary. If >>>>>>>>> "your discriminator =3D=3D 1" is received on a node which >>>> understands >>>>>>>>> this, then it is to map to shadow session. >>>>>>>>> De-multiplex success. >>>>>>>>>>=20 >>>>>>>>>> - Benefit of the redundancy concept is seen more on >>>>>>>>> distributed systems or a system having at least two cards >>>>>>>>> (ex: 2 route processor cards) which BFD can run actively. >>>>>>>>>> - Benefit of the redundancy concept is also seen more on >>>>>>>>> those BFD sessions which aren't tied to specific physical >>>>>> interfaces >>>>>>>>> (ex: multihop, logical/virtual interfaces). >>>>>>>>>> - Redundancy concept is applicable to both SW and HW based = BFD. >>>>>>>>>>=20 >>>>>>>>>> Scope of use case has limitations, in terms of system >>>>>>>>> architecture as well as BFD type, but for those that >>>> this applies >>>>>>>>> to, I still do see great benefits. >>>>>>>>>>=20 >>>>>>>>>>> We still have a possibility of colliding with existing >>>>>>>> sessions if >>>>>>>>>>> the remote side makes use of the reserved value. Bumping >>>>>>>>> the version >>>>>>>>>>> number is an obvious fix but if we're going to that extent >>>>>>>>> we need to >>>>>>>>>>> think more carefully about the full work we'd want under >>>>>>>>> such a rev. >>>>>>>>>>=20 >>>>>>>>>> I still do not see any implementations which cannot support >>>>>>>>> few more reserved discriminators. But a node speaking >>>> to another >>>>>>>>> which doesn't support added reserved discriminator range can >>>>>>>>> certainly cause undesired collision. And I agree that >>>> bumping the >>>>>>>>> version number would solve this easily. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Nobo >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >=20 From nobo@cisco.com Mon May 27 09:49:42 2013 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 46E7E21F96EF for ; Mon, 27 May 2013 09:49:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndo84V1MwdiG for ; Mon, 27 May 2013 09:49:36 -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 0E3C121F96F2 for ; Mon, 27 May 2013 09:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20505; q=dns/txt; s=iport; t=1369673376; x=1370882976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xLJ9ZMtzJJAAgUQoBPDg5Unm3TvLyTRgvHqhJvjD23k=; b=BYgB0FGegD3bRaDP++1nw4fnSswtaVRY5F0drHoz4J47DnizjjDbvqid jeFxp6j3SD0g/RbXeAOYFnoZ6NkrBX9gPMttgCnvn82fUJd6g/QgSDZm/ Syps7w6Gi3cXTAOuVxhiM16Txl+H56bkOiVqJauDT8JbTNuqb0nIunY8L Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAD2No1GtJXG+/2dsb2JhbABagmchwjaBBhZ0giMBAQEEOi0SDAQCAQgRAQMBAQEKCwkJBzIUAwYIAgQOBQiIBQG9TI1bCgESdDEHBgSCaWEDqHuDD4FoAQEHFx8 X-IronPort-AV: E=Sophos;i="4.87,752,1363132800"; d="scan'208";a="212457907" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 27 May 2013 16:49:35 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4RGnYnQ021440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 16:49:34 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 27 May 2013 11:49:34 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWpXi351GHcKw4ESBj+lSSrfkkJkY7wUAgAAEAwCAAASTAIAAB4EAgAAx5QD//+CUIIAAYk8A///BRnA= Date: Mon, 27 May 2013 16:49:33 +0000 Message-ID: References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <92DCCC04-A14C-46C5-9C64-AB3F0B389729@sniff.de> In-Reply-To: <92DCCC04-A14C-46C5-9C64-AB3F0B389729@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeff Haas \(jhaas@juniper.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, 27 May 2013 16:49:42 -0000 Hello Marc, If we conclude on extension without knowing usage requirements, we are at r= isk of defining it incorrectly. And we don't want to over-design to accommo= date many possibilities either. IMO, it's ok to discuss, it's not ok to con= clude, and "prepare" ... depends on what you mean. "address this in parallel" will be more beneficial if there was at least on= e solid usage requirement. Regards, Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, May 27, 2013 10:58 AM > To: Nobo Akiya (nobo) > Cc: Bhatia, Manav (Manav); Jeffrey Haas; Jeff Haas (jhaas@juniper.net); r= tg- > bfd@ietf.org > Subject: Re: The "version" topic (was: Reserved discriminators?) >=20 > Hello Nobo, >=20 > sorry when I disagree to some extend. We have to address this in parallel= . > Otherwise we end up with proposals for new usage that fall back into "how > to squeeze it into v1" - typically you will avoid de-railing your feature > discussion with the generic TLV/v2/whatever extension discussion, for los= s > of focus on the feature (and loss of progress, amount of time etc). >=20 > I do agree that the extension discussion becomes more relevant once the > BFD audience sees more cases that won't fit easily into v1. That should n= ot > stop us to prepare a good extension story. Doesn't mean this goes to RFC > anytime soon :-) >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On 2013-05-27, at 16:10 , Nobo Akiya (nobo) wrote: >=20 > > Hello Marc, Manav, > > > > As much as I would like to see more pieces to play with, I honestly don= 't > see sufficient reasons to define such (generically speaking). > > > > No matter how smart _how_ is, we will not get WG consensus without > people seeing great value(s). > > > > We should go back to discussing _if_ we need to define such. > > > > Regards, > > Nobo > > > > P.S. Your email is very interesting, I'll have to grab coffee and read = this > couple of more times. > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Monday, May 27, 2013 6:59 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); > >> rtg- bfd@ietf.org > >> Subject: Re: The "version" topic (was: Reserved discriminators?) > >> > >> Hello Manav, > >> > >> oh I'm sure for every proposal you will find someone who did this > >> already ;-) > >> > >> The point would be really that BFD is not restricted to IP and you > >> would need to make sure the transport mechanism always has some > length field. > >> > >> But I don't think we need this because ... > >> > >>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD > >>> data > >> block", where BFD data block is TLV encoded. The first 8 type values > >> would indicate that a certain kind of authentication scheme is > >> employed. The other values would mean something else. > >> > >> > >> ... this would be a much cleaner approach. As written in our private > >> communication I still think that the version approach is a better > >> fit, at least for cases where you don't need or don't want all the v1 > >> fields. Such a proposal then describes how to not use such fields, > >> where to deviate from > >> v1 ... practically you _do_ describe a new version (if you definition > >> of version isn't too strict) but with the risk of some > >> implementations stumbling as it's still a v1 packet. > >> > >> Now the version approach is based on one assumption: that > >> implementations do check the version field. Due to the BFD history > >> with v0 and v1 I have taken this for granted > >> > >> > >> Anyway, I'm glad we have the discussion. And I hope for more opinions > >> :-) > >> > >> > >> Best regards, > >> Marc > >> > >> > >> > >> > >> On 2013-05-27, at 10:00 , Bhatia, Manav (Manav) wrote: > >> > >>> Hi Marc, > >>> > >>> The "hack" that I have suggested already exists in OSPF!:) You can > >>> read RFC > >> 5613 for more sordid details. There are vendors that are shipping > >> code supporting this. I wager that if they were able to work around > >> the IP length issues in OSPF, then doing the same in BFD will not be t= oo > difficult! > >>> > >>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD > >>> data > >> block", where BFD data block is TLV encoded. The first 8 type values > >> would indicate that a certain kind of authentication scheme is > >> employed. The other values would mean something else. > >>> > >>> Cheers, Manav > >>> > >>>> -----Original Message----- > >>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>> Sent: Monday, May 27, 2013 1:03 PM > >>>> To: Bhatia, Manav (Manav) > >>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); > >>>> rtg-bfd@ietf.org > >>>> Subject: Re: The "version" topic (was: Reserved discriminators?) > >>>> > >>>> Hello Manav, > >>>> > >>>>> Backward incompatibility is HUGE issue > >>>> > >>>> that's why I talk about a version increase - not that the > >>>> incompatibility must be automatically a huge issue - to cleanly > >>>> separate things. > >>>> > >>>>> (especially since BFD is usually done in HW)! :) > >>>> > >>>> I have hardware implementations in mind as well. Exactly because > >>>> you are potentially less flexible in "hacking something in" it's > >>>> important to separate things. > >>>> > >>>> Besides: "usually" ... then we would see more really fast BFD > >>>> implementations out there, something that just started really. No, > >>>> 50msec interval is not really fast ;-) > >>>> > >>>> > >>>>> The BFD version 2 would only work when all participating > >>>> devices have upgraded to the new version. > >>>> > >>>> There is still this misunderstanding that v2 means we deprecate v1. > >>>> We don't. What we talk are new features. They will of course only > >>>> work in an interoperable way when all participants in the setup > >>>> support it - this has nothing to do with version numbers. > >>>> > >>>> > >>>>> All currently deployed routers will drop these packets as > >>>> they would consider the version field as invalid. > >>>> > >>>> Exactly that is the beauty, yes. If someone does not implement a > >>>> new feature then please please drop the packet. > >>>> > >>>> > >>>>> So, there must be a very sound reason for taking such a > >>>> drastic and a radical step - I don't think we have heard any that > >>>> warrants such a significant change! > >>>> > >>>> Manav, there is no reason naming this "drastic", "radical" or > >>>> whatever. When we introduce a new UDP port then equipment not > >>>> supporting it is dropping these packets too as no one is listening > >>>> to it. Haven't seen any such comments in such a case (and yes, when > >>>> you can do it with a new UDP port plus v1 then we go with v1. Not > >>>> all cases can be covered this way though) > >>>> > >>>> > >>>>> With my proposal you can incrementally add newer extensions > >>>> as the earlier boxes would simply ignore this extended data block > >>>> that carries the new stuff. > >>>> > >>>> Wrong. If the length is not correct then the packet is likely > >>>> dropped. If the packet is not dropped then you are in an undefined > >>>> area and can only hope for a "reasonable" > >>>> behaviour. Exactly such an undefined area is what I want to avoid. > >>>> Nor is processing of the new packet what you want in all cases. > >>>> > >>>> > >>>>> If youre not comfortable with adding stuff after the BFD > >>>> payload then we can always take up an Auth Type (say 9) which can > >>>> then be used to carry all the other interesting stuff. > >>>> > >>>> what has this to do with auth? This is what I name a "hack", > >>>> sorry. It's exactly my problem, we "work around" instead of > >>>> addressing a problem straight forward. > >>>> (I'm not surprised you bring up auth as this is an area you heavily > >>>> work on ;-) > >>>> > >>>> > >>>> Regards, Marc > >>>> > >>>> > >>>>> > >>>>> Cheers, Manav > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>>>> Sent: Monday, May 27, 2013 12:33 PM > >>>>>> To: Bhatia, Manav (Manav) > >>>>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas > >>>> (jhaas@juniper.net); > >>>>>> rtg-bfd@ietf.org; Marc Binderberger > >>>>>> Subject: Re: The "version" topic (was: Reserved discriminators?) > >>>>>> > >>>>>> Hello Manav, > >>>>>> > >>>>>> all fine and good - but I really don't understand this > >>>> avoidance of a > >>>>>> version change while we start looking for "ways to extend" > >>>> that all > >>>>>> have the one or other limit. What is the problem of thinking this > >>>>>> straight forward: you have a change - forget "substantial" > >>>> - or even > >>>>>> a re-interpretation in the header, then it _is_ a new version. > >>>>>> > >>>>>> Programming-wise this is clean, you have a well-defined indicator > >>>>>> that this packet needs a different treatment. > >>>>>> Nothing to conclude, not depending on IP header length - > >>>> BFD per se > >>>>>> is not IP related - and the right place is really the BFD header > >>>>>> itself when your idea is for the many BFD usages (IP, IP-less). > >>>>>> > >>>>>> The "backwards compatible" header I put in my last email > >>>> was just the > >>>>>> very few first fields. The rest may look very different. Even > >>>>>> when the rest of the header would have the same size of an v1 > >>>> header but I > >>>>>> interpret them differently, then that's not v1 anymore. > >>>>>> > >>>>>> > >>>>>> Regards, Marc > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: > >>>>>> > >>>>>>> Alternatively, we can use the "Authentication Present" bit > >>>>>> in the header to carry this additional block. > >>>>>>> > >>>>>>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a > >>>>>> standard we will never consume any more bits in the Auth Type as > >>>>>> this draft introduces a Key ID mechanism. This means that Auth > >>>>>> Type values beyond 8 are available to be used for other > >>>>>> mechanisms. > >>>>>>> > >>>>>>> We could for instance define value 8 meaning a BFD data > >>>>>> block. This can then be TLV encoded. > >>>>>>> > >>>>>>> This is again an example of how BFD can be extended while > >>>>>> remaining completely backward compatible -- without bumping the > >>>>>> version of BFD. > >>>>>>> > >>>>>>> Cheers, Manav > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: rtg-bfd-bounces@ietf.org > >>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, > >>>>>> Manav (Manav) > >>>>>>>> Sent: Monday, May 27, 2013 10:07 AM > >>>>>>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > >>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>>>>>> Subject: RE: The "version" topic (was: Reserved > >>>>>>>> discriminators?) > >>>>>>>> > >>>>>>>> Hi Marc, > >>>>>>>> > >>>>>>>> We usually do a version change when there is a very very > >>>>>> substantial > >>>>>>>> upgrade to the protocol - a kind that's usually non backward > >>>>>>>> compatible. > >>>>>>>> > >>>>>>>> If we really want to introduce newer fields to the packet > >>>>>> while being > >>>>>>>> backward compatible then the best approach imo is this: > >>>>>>>> > >>>>>>>> You stuff whatever additional information you want in a > >>>>>> special BFD > >>>>>>>> data block immediately at the end of the BFD packet. > >>>> Don't include > >>>>>>>> the length of this additional BFD block in the BFD header. > >>>>>> Instead, > >>>>>>>> account for this in the IPv4/IPv6 header length. > >>>>>>>> > >>>>>>>> +---------------------+ -- > >>>>>>>> | IP Header | ^ > >>>>>>>> | Length =3D HL+X+Y | | Header Length > >>>>>>>> | | v > >>>>>>>> +---------------------+ -- > >>>>>>>> | BFD Header | ^ > >>>>>>>> | Length =3D X | | > >>>>>>>> |.....................| | X > >>>>>>>> | | | > >>>>>>>> | BFD Data | > >>>>>>>> | | v > >>>>>>>> +---------------------+ -- > >>>>>>>> | | ^ > >>>>>>>> | BFD Data Block | Y > >>>>>>>> | | v > >>>>>>>> +---------------------+ -- > >>>>>>>> > >>>>>>>> How this additional BFD data block will be used is beyond > >>>>>> the scope > >>>>>>>> of the discussion right now. You could define that to be > >>>>>> TLV encoded > >>>>>>>> for ensuring easy extensibility. > >>>>>>>> > >>>>>>>> Implementations can either implicitly figure out the > >>>>>> presence of the > >>>>>>>> BFD data block by looking at the packet lengths in the > >>>>>> headers or can > >>>>>>>> explicitly be indicated in the BFD header. > >>>>>>>> > >>>>>>>> If people think it's a worthwhile idea to pursue then > >>>> this can be > >>>>>>>> quickly drafted. > >>>>>>>> > >>>>>>>> Cheers, Manav > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: rtg-bfd-bounces@ietf.org > >>>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > >>>>>>>>> Binderberger > >>>>>>>>> Sent: Sunday, May 26, 2013 6:49 PM > >>>>>>>>> To: Jeffrey Haas; Nobo Akiya (nobo) > >>>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>>>>>>> Subject: The "version" topic (was: Reserved discriminators?) > >>>>>>>>> > >>>>>>>>> Hello everyone, > >>>>>>>>> > >>>>>>>>> sorry for me delayed response. > >>>>>>>>> > >>>>>>>>> Taking a step back. If we would write RFC5880 today then we > >>>>>>>> probably > >>>>>>>>> would have reserved a small number of discriminators, e.g. > >>>>>>>> the first 8 > >>>>>>>>> or 16 values. But RFC5880 is since 3 years out, the > >>>>>>>> underlying draft > >>>>>>>>> is even much older. The statement in the Spec is > >>>>>> effectively: dear > >>>>>>>>> implementor, beside the zero value do what you like with > >>>>>>>> this value. > >>>>>>>>> We cannot claim back parts of the number space without risking > >>>>>>>>> problems. > >>>>>>>>> > >>>>>>>>> This is why I tend more and more to have clean separation, > >>>>>>>> be it a new > >>>>>>>>> IP/UDP port like BFD-on-lags or be it a new version number. > >>>>>>>> The latter > >>>>>>>>> faces, I think, largely a psychological problem :-) > >>>>>>>>> > >>>>>>>>> Independent if Nobo and me can convince this audience about > >>>>>>>>> the redundancy concept we propose - working on it - I do see > >>>>>>>>> more > >>>>>>>>> (private) ideas that cover BFD sessions in a general sense, > >>>>>>>> i.e. cover > >>>>>>>>> the various RFCs, single-, multi-hop, with/withou label and > >>>>>>>> so on. In > >>>>>>>>> all cases I see people spending time to "fiddle about the > >>>>>>>> bits" of the > >>>>>>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how > >>>>>>>> wicked the > >>>>>>>>> new definitions become, not to mention the difficulties for > >>>>>>>>> implementations and for interop. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Yes, we have a limited number of versions available. > >>>> Let me throw > >>>>>>>>> this idea at the BFD audience: the base v2 header would > >>>> look like > >>>>>>>>> this: > >>>>>>>>> > >>>>>>>>> 0 1 2 3 > >>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >>>> 7 8 9 0 1 > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> |0 1 0| Subtype | TBD, depending on Subtype | > >>>>>> Length | > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> | My Discriminator > >>>>>> | > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> | Your Discriminator > >>>>>> | > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> | ... > >>>>>> | > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The subtype (the former Diag field) would allow for 32 new > >>>>>>>>> definitions. Actually I do not hope myself we define so many > >>>>>>>>> variations ;-) but it opens up room that we do not have > >>>> with the > >>>>>>>>> version field alone. > >>>>>>>>> > >>>>>>>>> To emphasize: defining a v2 header does not mean v1 is > >>>>>> obsolete. BFD > >>>>>>>>> v1 works great, I'm not trying to replace it and whenever > >>>>>> it can be > >>>>>>>>> used it must be used. > >>>>>>>>> > >>>>>>>>> For the other fields above, just quickly my thoughts (if > >>>>>> we want to > >>>>>>>>> dive deeper into this I better write a draft to discuss): > >>>>>>>>> > >>>>>>>>> - length field remains in it's position, for ease of > >>>>>> implementation > >>>>>>>>> > >>>>>>>>> - of course I keep the discriminator concept - or it > >>>>>> wouldn't be BFD > >>>>>>>>> anymore ;-) and I keep them again at the same position > >>>>>> (the coders > >>>>>>>>> of NP, FPGA etc never have enough cycles or gates. And > >>>>>> these fields > >>>>>>>>> are used "in hardware") > >>>>>>>>> > >>>>>>>>> - not obvious here but I would define a relatively strict > >>>>>> upper size > >>>>>>>>> limit. I'm not proposing a generic TLV format, based on the > >>>>>>>>> difficulties I know about implementing really fast I/O it > >>>>>> is better > >>>>>>>>> to have fixed formats, IMHO. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Feedback is very welcome. And yes, I have mixed emotions > >>>>>> myself to > >>>>>>>>> let the genie out of the bottle :-) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks & Regards, > >>>>>>>>> Marc > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: > >>>>>>>>> > >>>>>>>>>> Hello Jeff, et al, > >>>>>>>>>> > >>>>>>>>>>> But, if the reserved value was used *only* for the context > >>>>>>>>> of telling > >>>>>>>>>>> the remote side "this is your redundant connection", and > >>>>>>>>>>> some reserved value was used in Down state for Your > >>>>>>>>> Discriminator to help > >>>>>>>>>>> with de-multiplexing (e.g. > >>>>>>>>>>> 1 or 0xffffffff), that would be sufficient. > >>>>>>>>>> > >>>>>>>>>> Correct, that was my thoughts. Let's say reserved value > >>>>>>>>> one(1) was used for shadow session bootstrapping purpose. > >>>>>>>>> Value one(1) of shadow is equivalent of value zero(0) of > >>>>>> primary. If > >>>>>>>>> "your discriminator =3D=3D 1" is received on a node which > >>>> understands > >>>>>>>>> this, then it is to map to shadow session. > >>>>>>>>> De-multiplex success. > >>>>>>>>>> > >>>>>>>>>> - Benefit of the redundancy concept is seen more on > >>>>>>>>> distributed systems or a system having at least two cards > >>>>>>>>> (ex: 2 route processor cards) which BFD can run actively. > >>>>>>>>>> - Benefit of the redundancy concept is also seen more on > >>>>>>>>> those BFD sessions which aren't tied to specific physical > >>>>>> interfaces > >>>>>>>>> (ex: multihop, logical/virtual interfaces). > >>>>>>>>>> - Redundancy concept is applicable to both SW and HW based > BFD. > >>>>>>>>>> > >>>>>>>>>> Scope of use case has limitations, in terms of system > >>>>>>>>> architecture as well as BFD type, but for those that > >>>> this applies > >>>>>>>>> to, I still do see great benefits. > >>>>>>>>>> > >>>>>>>>>>> We still have a possibility of colliding with existing > >>>>>>>> sessions if > >>>>>>>>>>> the remote side makes use of the reserved value. Bumping > >>>>>>>>> the version > >>>>>>>>>>> number is an obvious fix but if we're going to that extent > >>>>>>>>> we need to > >>>>>>>>>>> think more carefully about the full work we'd want under > >>>>>>>>> such a rev. > >>>>>>>>>> > >>>>>>>>>> I still do not see any implementations which cannot support > >>>>>>>>> few more reserved discriminators. But a node speaking > >>>> to another > >>>>>>>>> which doesn't support added reserved discriminator range can > >>>>>>>>> certainly cause undesired collision. And I agree that > >>>> bumping the > >>>>>>>>> version number would solve this easily. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Nobo > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > > From davari@broadcom.com Tue May 28 11:52:10 2013 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 195FC21F94B1 for ; Tue, 28 May 2013 11:52:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idhXxhEGzfRR for ; Tue, 28 May 2013 11:52:03 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 67AE821F91C4 for ; Tue, 28 May 2013 11:52:03 -0700 (PDT) Received: from [10.9.208.53] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 28 May 2013 11:48:18 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 28 May 2013 11:51:54 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Tue, 28 May 2013 11:51:54 -0700 From: "Shahram Davari" To: "Nobo Akiya (nobo)" , "Marc Binderberger" Subject: RE: The "version" topic (was: Reserved discriminators?) Thread-Topic: The "version" topic (was: Reserved discriminators?) Thread-Index: AQHOWpXvP8lYg/p6iEWFN4/ij7n7hpkZEIwAgAAEAwCAAASTAIAAB4EAgAAx5QCAADVrAIAADXgAgAAfFYCAAT2nYA== Date: Tue, 28 May 2013 18:51:54 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BE0B20F@SJEXCHMB12.corp.ad.broadcom.com> References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <92DCCC04-A14C-46C5-9C64-AB3F0B389729@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DBA247831W27749057-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Jeff Haas \(jhaas@juniper.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: Tue, 28 May 2013 18:52:10 -0000 Hi, Before going any further I suggest whoever is proposing this to write a req= uirements drafts so that we can better evaluate what is needed and why it i= s required. The next step after that is to evaluate the solutions. May be j= ust a single flag in the header is all that is required or may be a new ver= sion is needed. Thanks Shahram -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Nobo Akiya (nobo) Sent: Monday, May 27, 2013 9:50 AM To: Marc Binderberger Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org Subject: RE: The "version" topic (was: Reserved discriminators?) Hello Marc, If we conclude on extension without knowing usage requirements, we are at r= isk of defining it incorrectly. And we don't want to over-design to accommo= date many possibilities either. IMO, it's ok to discuss, it's not ok to con= clude, and "prepare" ... depends on what you mean. "address this in parallel" will be more beneficial if there was at least on= e solid usage requirement. Regards, Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, May 27, 2013 10:58 AM > To: Nobo Akiya (nobo) > Cc: Bhatia, Manav (Manav); Jeffrey Haas; Jeff Haas (jhaas@juniper.net); r= tg- > bfd@ietf.org > Subject: Re: The "version" topic (was: Reserved discriminators?) >=20 > Hello Nobo, >=20 > sorry when I disagree to some extend. We have to address this in parallel= . > Otherwise we end up with proposals for new usage that fall back into "how > to squeeze it into v1" - typically you will avoid de-railing your feature > discussion with the generic TLV/v2/whatever extension discussion, for los= s > of focus on the feature (and loss of progress, amount of time etc). >=20 > I do agree that the extension discussion becomes more relevant once the > BFD audience sees more cases that won't fit easily into v1. That should n= ot > stop us to prepare a good extension story. Doesn't mean this goes to RFC > anytime soon :-) >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On 2013-05-27, at 16:10 , Nobo Akiya (nobo) wrote: >=20 > > Hello Marc, Manav, > > > > As much as I would like to see more pieces to play with, I honestly don= 't > see sufficient reasons to define such (generically speaking). > > > > No matter how smart _how_ is, we will not get WG consensus without > people seeing great value(s). > > > > We should go back to discussing _if_ we need to define such. > > > > Regards, > > Nobo > > > > P.S. Your email is very interesting, I'll have to grab coffee and read = this > couple of more times. > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Monday, May 27, 2013 6:59 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); > >> rtg- bfd@ietf.org > >> Subject: Re: The "version" topic (was: Reserved discriminators?) > >> > >> Hello Manav, > >> > >> oh I'm sure for every proposal you will find someone who did this > >> already ;-) > >> > >> The point would be really that BFD is not restricted to IP and you > >> would need to make sure the transport mechanism always has some > length field. > >> > >> But I don't think we need this because ... > >> > >>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD > >>> data > >> block", where BFD data block is TLV encoded. The first 8 type values > >> would indicate that a certain kind of authentication scheme is > >> employed. The other values would mean something else. > >> > >> > >> ... this would be a much cleaner approach. As written in our private > >> communication I still think that the version approach is a better > >> fit, at least for cases where you don't need or don't want all the v1 > >> fields. Such a proposal then describes how to not use such fields, > >> where to deviate from > >> v1 ... practically you _do_ describe a new version (if you definition > >> of version isn't too strict) but with the risk of some > >> implementations stumbling as it's still a v1 packet. > >> > >> Now the version approach is based on one assumption: that > >> implementations do check the version field. Due to the BFD history > >> with v0 and v1 I have taken this for granted > >> > >> > >> Anyway, I'm glad we have the discussion. And I hope for more opinions > >> :-) > >> > >> > >> Best regards, > >> Marc > >> > >> > >> > >> > >> On 2013-05-27, at 10:00 , Bhatia, Manav (Manav) wrote: > >> > >>> Hi Marc, > >>> > >>> The "hack" that I have suggested already exists in OSPF!:) You can > >>> read RFC > >> 5613 for more sordid details. There are vendors that are shipping > >> code supporting this. I wager that if they were able to work around > >> the IP length issues in OSPF, then doing the same in BFD will not be t= oo > difficult! > >>> > >>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD > >>> data > >> block", where BFD data block is TLV encoded. The first 8 type values > >> would indicate that a certain kind of authentication scheme is > >> employed. The other values would mean something else. > >>> > >>> Cheers, Manav > >>> > >>>> -----Original Message----- > >>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>> Sent: Monday, May 27, 2013 1:03 PM > >>>> To: Bhatia, Manav (Manav) > >>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); > >>>> rtg-bfd@ietf.org > >>>> Subject: Re: The "version" topic (was: Reserved discriminators?) > >>>> > >>>> Hello Manav, > >>>> > >>>>> Backward incompatibility is HUGE issue > >>>> > >>>> that's why I talk about a version increase - not that the > >>>> incompatibility must be automatically a huge issue - to cleanly > >>>> separate things. > >>>> > >>>>> (especially since BFD is usually done in HW)! :) > >>>> > >>>> I have hardware implementations in mind as well. Exactly because > >>>> you are potentially less flexible in "hacking something in" it's > >>>> important to separate things. > >>>> > >>>> Besides: "usually" ... then we would see more really fast BFD > >>>> implementations out there, something that just started really. No, > >>>> 50msec interval is not really fast ;-) > >>>> > >>>> > >>>>> The BFD version 2 would only work when all participating > >>>> devices have upgraded to the new version. > >>>> > >>>> There is still this misunderstanding that v2 means we deprecate v1. > >>>> We don't. What we talk are new features. They will of course only > >>>> work in an interoperable way when all participants in the setup > >>>> support it - this has nothing to do with version numbers. > >>>> > >>>> > >>>>> All currently deployed routers will drop these packets as > >>>> they would consider the version field as invalid. > >>>> > >>>> Exactly that is the beauty, yes. If someone does not implement a > >>>> new feature then please please drop the packet. > >>>> > >>>> > >>>>> So, there must be a very sound reason for taking such a > >>>> drastic and a radical step - I don't think we have heard any that > >>>> warrants such a significant change! > >>>> > >>>> Manav, there is no reason naming this "drastic", "radical" or > >>>> whatever. When we introduce a new UDP port then equipment not > >>>> supporting it is dropping these packets too as no one is listening > >>>> to it. Haven't seen any such comments in such a case (and yes, when > >>>> you can do it with a new UDP port plus v1 then we go with v1. Not > >>>> all cases can be covered this way though) > >>>> > >>>> > >>>>> With my proposal you can incrementally add newer extensions > >>>> as the earlier boxes would simply ignore this extended data block > >>>> that carries the new stuff. > >>>> > >>>> Wrong. If the length is not correct then the packet is likely > >>>> dropped. If the packet is not dropped then you are in an undefined > >>>> area and can only hope for a "reasonable" > >>>> behaviour. Exactly such an undefined area is what I want to avoid. > >>>> Nor is processing of the new packet what you want in all cases. > >>>> > >>>> > >>>>> If youre not comfortable with adding stuff after the BFD > >>>> payload then we can always take up an Auth Type (say 9) which can > >>>> then be used to carry all the other interesting stuff. > >>>> > >>>> what has this to do with auth? This is what I name a "hack", > >>>> sorry. It's exactly my problem, we "work around" instead of > >>>> addressing a problem straight forward. > >>>> (I'm not surprised you bring up auth as this is an area you heavily > >>>> work on ;-) > >>>> > >>>> > >>>> Regards, Marc > >>>> > >>>> > >>>>> > >>>>> Cheers, Manav > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>>>> Sent: Monday, May 27, 2013 12:33 PM > >>>>>> To: Bhatia, Manav (Manav) > >>>>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas > >>>> (jhaas@juniper.net); > >>>>>> rtg-bfd@ietf.org; Marc Binderberger > >>>>>> Subject: Re: The "version" topic (was: Reserved discriminators?) > >>>>>> > >>>>>> Hello Manav, > >>>>>> > >>>>>> all fine and good - but I really don't understand this > >>>> avoidance of a > >>>>>> version change while we start looking for "ways to extend" > >>>> that all > >>>>>> have the one or other limit. What is the problem of thinking this > >>>>>> straight forward: you have a change - forget "substantial" > >>>> - or even > >>>>>> a re-interpretation in the header, then it _is_ a new version. > >>>>>> > >>>>>> Programming-wise this is clean, you have a well-defined indicator > >>>>>> that this packet needs a different treatment. > >>>>>> Nothing to conclude, not depending on IP header length - > >>>> BFD per se > >>>>>> is not IP related - and the right place is really the BFD header > >>>>>> itself when your idea is for the many BFD usages (IP, IP-less). > >>>>>> > >>>>>> The "backwards compatible" header I put in my last email > >>>> was just the > >>>>>> very few first fields. The rest may look very different. Even > >>>>>> when the rest of the header would have the same size of an v1 > >>>> header but I > >>>>>> interpret them differently, then that's not v1 anymore. > >>>>>> > >>>>>> > >>>>>> Regards, Marc > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: > >>>>>> > >>>>>>> Alternatively, we can use the "Authentication Present" bit > >>>>>> in the header to carry this additional block. > >>>>>>> > >>>>>>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a > >>>>>> standard we will never consume any more bits in the Auth Type as > >>>>>> this draft introduces a Key ID mechanism. This means that Auth > >>>>>> Type values beyond 8 are available to be used for other > >>>>>> mechanisms. > >>>>>>> > >>>>>>> We could for instance define value 8 meaning a BFD data > >>>>>> block. This can then be TLV encoded. > >>>>>>> > >>>>>>> This is again an example of how BFD can be extended while > >>>>>> remaining completely backward compatible -- without bumping the > >>>>>> version of BFD. > >>>>>>> > >>>>>>> Cheers, Manav > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: rtg-bfd-bounces@ietf.org > >>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, > >>>>>> Manav (Manav) > >>>>>>>> Sent: Monday, May 27, 2013 10:07 AM > >>>>>>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) > >>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>>>>>> Subject: RE: The "version" topic (was: Reserved > >>>>>>>> discriminators?) > >>>>>>>> > >>>>>>>> Hi Marc, > >>>>>>>> > >>>>>>>> We usually do a version change when there is a very very > >>>>>> substantial > >>>>>>>> upgrade to the protocol - a kind that's usually non backward > >>>>>>>> compatible. > >>>>>>>> > >>>>>>>> If we really want to introduce newer fields to the packet > >>>>>> while being > >>>>>>>> backward compatible then the best approach imo is this: > >>>>>>>> > >>>>>>>> You stuff whatever additional information you want in a > >>>>>> special BFD > >>>>>>>> data block immediately at the end of the BFD packet. > >>>> Don't include > >>>>>>>> the length of this additional BFD block in the BFD header. > >>>>>> Instead, > >>>>>>>> account for this in the IPv4/IPv6 header length. > >>>>>>>> > >>>>>>>> +---------------------+ -- > >>>>>>>> | IP Header | ^ > >>>>>>>> | Length =3D HL+X+Y | | Header Length > >>>>>>>> | | v > >>>>>>>> +---------------------+ -- > >>>>>>>> | BFD Header | ^ > >>>>>>>> | Length =3D X | | > >>>>>>>> |.....................| | X > >>>>>>>> | | | > >>>>>>>> | BFD Data | > >>>>>>>> | | v > >>>>>>>> +---------------------+ -- > >>>>>>>> | | ^ > >>>>>>>> | BFD Data Block | Y > >>>>>>>> | | v > >>>>>>>> +---------------------+ -- > >>>>>>>> > >>>>>>>> How this additional BFD data block will be used is beyond > >>>>>> the scope > >>>>>>>> of the discussion right now. You could define that to be > >>>>>> TLV encoded > >>>>>>>> for ensuring easy extensibility. > >>>>>>>> > >>>>>>>> Implementations can either implicitly figure out the > >>>>>> presence of the > >>>>>>>> BFD data block by looking at the packet lengths in the > >>>>>> headers or can > >>>>>>>> explicitly be indicated in the BFD header. > >>>>>>>> > >>>>>>>> If people think it's a worthwhile idea to pursue then > >>>> this can be > >>>>>>>> quickly drafted. > >>>>>>>> > >>>>>>>> Cheers, Manav > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: rtg-bfd-bounces@ietf.org > >>>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > >>>>>>>>> Binderberger > >>>>>>>>> Sent: Sunday, May 26, 2013 6:49 PM > >>>>>>>>> To: Jeffrey Haas; Nobo Akiya (nobo) > >>>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >>>>>>>>> Subject: The "version" topic (was: Reserved discriminators?) > >>>>>>>>> > >>>>>>>>> Hello everyone, > >>>>>>>>> > >>>>>>>>> sorry for me delayed response. > >>>>>>>>> > >>>>>>>>> Taking a step back. If we would write RFC5880 today then we > >>>>>>>> probably > >>>>>>>>> would have reserved a small number of discriminators, e.g. > >>>>>>>> the first 8 > >>>>>>>>> or 16 values. But RFC5880 is since 3 years out, the > >>>>>>>> underlying draft > >>>>>>>>> is even much older. The statement in the Spec is > >>>>>> effectively: dear > >>>>>>>>> implementor, beside the zero value do what you like with > >>>>>>>> this value. > >>>>>>>>> We cannot claim back parts of the number space without risking > >>>>>>>>> problems. > >>>>>>>>> > >>>>>>>>> This is why I tend more and more to have clean separation, > >>>>>>>> be it a new > >>>>>>>>> IP/UDP port like BFD-on-lags or be it a new version number. > >>>>>>>> The latter > >>>>>>>>> faces, I think, largely a psychological problem :-) > >>>>>>>>> > >>>>>>>>> Independent if Nobo and me can convince this audience about > >>>>>>>>> the redundancy concept we propose - working on it - I do see > >>>>>>>>> more > >>>>>>>>> (private) ideas that cover BFD sessions in a general sense, > >>>>>>>> i.e. cover > >>>>>>>>> the various RFCs, single-, multi-hop, with/withou label and > >>>>>>>> so on. In > >>>>>>>>> all cases I see people spending time to "fiddle about the > >>>>>>>> bits" of the > >>>>>>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how > >>>>>>>> wicked the > >>>>>>>>> new definitions become, not to mention the difficulties for > >>>>>>>>> implementations and for interop. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Yes, we have a limited number of versions available. > >>>> Let me throw > >>>>>>>>> this idea at the BFD audience: the base v2 header would > >>>> look like > >>>>>>>>> this: > >>>>>>>>> > >>>>>>>>> 0 1 2 3 > >>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >>>> 7 8 9 0 1 > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> |0 1 0| Subtype | TBD, depending on Subtype | > >>>>>> Length | > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> | My Discriminator > >>>>>> | > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> | Your Discriminator > >>>>>> | > >>>>>>>>> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>>>>> | ... > >>>>>> | > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The subtype (the former Diag field) would allow for 32 new > >>>>>>>>> definitions. Actually I do not hope myself we define so many > >>>>>>>>> variations ;-) but it opens up room that we do not have > >>>> with the > >>>>>>>>> version field alone. > >>>>>>>>> > >>>>>>>>> To emphasize: defining a v2 header does not mean v1 is > >>>>>> obsolete. BFD > >>>>>>>>> v1 works great, I'm not trying to replace it and whenever > >>>>>> it can be > >>>>>>>>> used it must be used. > >>>>>>>>> > >>>>>>>>> For the other fields above, just quickly my thoughts (if > >>>>>> we want to > >>>>>>>>> dive deeper into this I better write a draft to discuss): > >>>>>>>>> > >>>>>>>>> - length field remains in it's position, for ease of > >>>>>> implementation > >>>>>>>>> > >>>>>>>>> - of course I keep the discriminator concept - or it > >>>>>> wouldn't be BFD > >>>>>>>>> anymore ;-) and I keep them again at the same position > >>>>>> (the coders > >>>>>>>>> of NP, FPGA etc never have enough cycles or gates. And > >>>>>> these fields > >>>>>>>>> are used "in hardware") > >>>>>>>>> > >>>>>>>>> - not obvious here but I would define a relatively strict > >>>>>> upper size > >>>>>>>>> limit. I'm not proposing a generic TLV format, based on the > >>>>>>>>> difficulties I know about implementing really fast I/O it > >>>>>> is better > >>>>>>>>> to have fixed formats, IMHO. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Feedback is very welcome. And yes, I have mixed emotions > >>>>>> myself to > >>>>>>>>> let the genie out of the bottle :-) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks & Regards, > >>>>>>>>> Marc > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: > >>>>>>>>> > >>>>>>>>>> Hello Jeff, et al, > >>>>>>>>>> > >>>>>>>>>>> But, if the reserved value was used *only* for the context > >>>>>>>>> of telling > >>>>>>>>>>> the remote side "this is your redundant connection", and > >>>>>>>>>>> some reserved value was used in Down state for Your > >>>>>>>>> Discriminator to help > >>>>>>>>>>> with de-multiplexing (e.g. > >>>>>>>>>>> 1 or 0xffffffff), that would be sufficient. > >>>>>>>>>> > >>>>>>>>>> Correct, that was my thoughts. Let's say reserved value > >>>>>>>>> one(1) was used for shadow session bootstrapping purpose. > >>>>>>>>> Value one(1) of shadow is equivalent of value zero(0) of > >>>>>> primary. If > >>>>>>>>> "your discriminator =3D=3D 1" is received on a node which > >>>> understands > >>>>>>>>> this, then it is to map to shadow session. > >>>>>>>>> De-multiplex success. > >>>>>>>>>> > >>>>>>>>>> - Benefit of the redundancy concept is seen more on > >>>>>>>>> distributed systems or a system having at least two cards > >>>>>>>>> (ex: 2 route processor cards) which BFD can run actively. > >>>>>>>>>> - Benefit of the redundancy concept is also seen more on > >>>>>>>>> those BFD sessions which aren't tied to specific physical > >>>>>> interfaces > >>>>>>>>> (ex: multihop, logical/virtual interfaces). > >>>>>>>>>> - Redundancy concept is applicable to both SW and HW based > BFD. > >>>>>>>>>> > >>>>>>>>>> Scope of use case has limitations, in terms of system > >>>>>>>>> architecture as well as BFD type, but for those that > >>>> this applies > >>>>>>>>> to, I still do see great benefits. > >>>>>>>>>> > >>>>>>>>>>> We still have a possibility of colliding with existing > >>>>>>>> sessions if > >>>>>>>>>>> the remote side makes use of the reserved value. Bumping > >>>>>>>>> the version > >>>>>>>>>>> number is an obvious fix but if we're going to that extent > >>>>>>>>> we need to > >>>>>>>>>>> think more carefully about the full work we'd want under > >>>>>>>>> such a rev. > >>>>>>>>>> > >>>>>>>>>> I still do not see any implementations which cannot support > >>>>>>>>> few more reserved discriminators. But a node speaking > >>>> to another > >>>>>>>>> which doesn't support added reserved discriminator range can > >>>>>>>>> certainly cause undesired collision. And I agree that > >>>> bumping the > >>>>>>>>> version number would solve this easily. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Nobo > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > > From marc@sniff.de Wed May 29 06:32:17 2013 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 331A121F8F0A for ; Wed, 29 May 2013 06:32:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swm6Gm0uc-jw for ; Wed, 29 May 2013 06:32:14 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42521F9092 for ; Wed, 29 May 2013 06:32:08 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4923C2AA11; Wed, 29 May 2013 13:32:06 +0000 (GMT) Subject: Re: The "version" topic (was: Reserved discriminators?) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BE0B20F@SJEXCHMB12.corp.ad.broadcom.com> Date: Wed, 29 May 2013 15:32:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130515150757.GN5406@pfrc> <8F97999B-CD9E-40E0-A1F8-37530F063FF6@sniff.de> <20211F91F544D247976D84C5D778A4C30344C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <92DCCC04-A14C-46C5-9C64-AB3F0B389729@sniff.de> <4A6CE49E6084B141B15C0713B8993F281BE0B20F@SJEXCHMB12.corp.ad.broadcom.com> To: Shahram Davari X-Mailer: Apple Mail (2.1084) Cc: "Jeff Haas \(jhaas@juniper.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: Wed, 29 May 2013 13:32:17 -0000 Hello Shahram, I learned meanwhile that Nobo plans to come out with a new draft in the = near future (*), which would as a side effect also cover the redundancy. Your comment is absolutely valid and we better put the new draft on the = table before discussing the "what" and "why". > May be just a single flag in the header A kingdom for some header space for new flags! :-) Thanks for your feedback, best regards, Marc (*: no questions please, no sneak preview - we all just wait for Nobo's = submission ;-) On 2013-05-28, at 20:51 , Shahram Davari wrote: > Hi, >=20 > Before going any further I suggest whoever is proposing this to write = a requirements drafts so that we can better evaluate what is needed and = why it is required. The next step after that is to evaluate the = solutions. May be just a single flag in the header is all that is = required or may be a new version is needed. >=20 > Thanks > Shahram >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Nobo Akiya (nobo) > Sent: Monday, May 27, 2013 9:50 AM > To: Marc Binderberger > Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > Subject: RE: The "version" topic (was: Reserved discriminators?) >=20 > Hello Marc, >=20 > If we conclude on extension without knowing usage requirements, we are = at risk of defining it incorrectly. And we don't want to over-design to = accommodate many possibilities either. IMO, it's ok to discuss, it's not = ok to conclude, and "prepare" ... depends on what you mean. >=20 > "address this in parallel" will be more beneficial if there was at = least one solid usage requirement. >=20 > Regards, > Nobo >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, May 27, 2013 10:58 AM >> To: Nobo Akiya (nobo) >> Cc: Bhatia, Manav (Manav); Jeffrey Haas; Jeff Haas = (jhaas@juniper.net); rtg- >> bfd@ietf.org >> Subject: Re: The "version" topic (was: Reserved discriminators?) >>=20 >> Hello Nobo, >>=20 >> sorry when I disagree to some extend. We have to address this in = parallel. >> Otherwise we end up with proposals for new usage that fall back into = "how >> to squeeze it into v1" - typically you will avoid de-railing your = feature >> discussion with the generic TLV/v2/whatever extension discussion, for = loss >> of focus on the feature (and loss of progress, amount of time etc). >>=20 >> I do agree that the extension discussion becomes more relevant once = the >> BFD audience sees more cases that won't fit easily into v1. That = should not >> stop us to prepare a good extension story. Doesn't mean this goes to = RFC >> anytime soon :-) >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >>=20 >> On 2013-05-27, at 16:10 , Nobo Akiya (nobo) wrote: >>=20 >>> Hello Marc, Manav, >>>=20 >>> As much as I would like to see more pieces to play with, I honestly = don't >> see sufficient reasons to define such (generically speaking). >>>=20 >>> No matter how smart _how_ is, we will not get WG consensus without >> people seeing great value(s). >>>=20 >>> We should go back to discussing _if_ we need to define such. >>>=20 >>> Regards, >>> Nobo >>>=20 >>> P.S. Your email is very interesting, I'll have to grab coffee and = read this >> couple of more times. >>>=20 >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>> Sent: Monday, May 27, 2013 6:59 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); >>>> rtg- bfd@ietf.org >>>> Subject: Re: The "version" topic (was: Reserved discriminators?) >>>>=20 >>>> Hello Manav, >>>>=20 >>>> oh I'm sure for every proposal you will find someone who did this >>>> already ;-) >>>>=20 >>>> The point would be really that BFD is not restricted to IP and you >>>> would need to make sure the transport mechanism always has some >> length field. >>>>=20 >>>> But I don't think we need this because ... >>>>=20 >>>>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD >>>>> data >>>> block", where BFD data block is TLV encoded. The first 8 type = values >>>> would indicate that a certain kind of authentication scheme is >>>> employed. The other values would mean something else. >>>>=20 >>>>=20 >>>> ... this would be a much cleaner approach. As written in our = private >>>> communication I still think that the version approach is a better >>>> fit, at least for cases where you don't need or don't want all the = v1 >>>> fields. Such a proposal then describes how to not use such fields, >>>> where to deviate from >>>> v1 ... practically you _do_ describe a new version (if you = definition >>>> of version isn't too strict) but with the risk of some >>>> implementations stumbling as it's still a v1 packet. >>>>=20 >>>> Now the version approach is based on one assumption: that >>>> implementations do check the version field. Due to the BFD history >>>> with v0 and v1 I have taken this for granted >>>>=20 >>>>=20 >>>> Anyway, I'm glad we have the discussion. And I hope for more = opinions >>>> :-) >>>>=20 >>>>=20 >>>> Best regards, >>>> Marc >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-27, at 10:00 , Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> Hi Marc, >>>>>=20 >>>>> The "hack" that I have suggested already exists in OSPF!:) You can >>>>> read RFC >>>> 5613 for more sordid details. There are vendors that are shipping >>>> code supporting this. I wager that if they were able to work around >>>> the IP length issues in OSPF, then doing the same in BFD will not = be too >> difficult! >>>>>=20 >>>>> Would it help if 5880bis redefines the "Auth Present" bit as "BFD >>>>> data >>>> block", where BFD data block is TLV encoded. The first 8 type = values >>>> would indicate that a certain kind of authentication scheme is >>>> employed. The other values would mean something else. >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>> Sent: Monday, May 27, 2013 1:03 PM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas = (jhaas@juniper.net); >>>>>> rtg-bfd@ietf.org >>>>>> Subject: Re: The "version" topic (was: Reserved discriminators?) >>>>>>=20 >>>>>> Hello Manav, >>>>>>=20 >>>>>>> Backward incompatibility is HUGE issue >>>>>>=20 >>>>>> that's why I talk about a version increase - not that the >>>>>> incompatibility must be automatically a huge issue - to cleanly >>>>>> separate things. >>>>>>=20 >>>>>>> (especially since BFD is usually done in HW)! :) >>>>>>=20 >>>>>> I have hardware implementations in mind as well. Exactly because >>>>>> you are potentially less flexible in "hacking something in" it's >>>>>> important to separate things. >>>>>>=20 >>>>>> Besides: "usually" ... then we would see more really fast BFD >>>>>> implementations out there, something that just started really. = No, >>>>>> 50msec interval is not really fast ;-) >>>>>>=20 >>>>>>=20 >>>>>>> The BFD version 2 would only work when all participating >>>>>> devices have upgraded to the new version. >>>>>>=20 >>>>>> There is still this misunderstanding that v2 means we deprecate = v1. >>>>>> We don't. What we talk are new features. They will of course only >>>>>> work in an interoperable way when all participants in the setup >>>>>> support it - this has nothing to do with version numbers. >>>>>>=20 >>>>>>=20 >>>>>>> All currently deployed routers will drop these packets as >>>>>> they would consider the version field as invalid. >>>>>>=20 >>>>>> Exactly that is the beauty, yes. If someone does not implement a >>>>>> new feature then please please drop the packet. >>>>>>=20 >>>>>>=20 >>>>>>> So, there must be a very sound reason for taking such a >>>>>> drastic and a radical step - I don't think we have heard any that >>>>>> warrants such a significant change! >>>>>>=20 >>>>>> Manav, there is no reason naming this "drastic", "radical" or >>>>>> whatever. When we introduce a new UDP port then equipment not >>>>>> supporting it is dropping these packets too as no one is = listening >>>>>> to it. Haven't seen any such comments in such a case (and yes, = when >>>>>> you can do it with a new UDP port plus v1 then we go with v1. Not >>>>>> all cases can be covered this way though) >>>>>>=20 >>>>>>=20 >>>>>>> With my proposal you can incrementally add newer extensions >>>>>> as the earlier boxes would simply ignore this extended data block >>>>>> that carries the new stuff. >>>>>>=20 >>>>>> Wrong. If the length is not correct then the packet is likely >>>>>> dropped. If the packet is not dropped then you are in an = undefined >>>>>> area and can only hope for a "reasonable" >>>>>> behaviour. Exactly such an undefined area is what I want to = avoid. >>>>>> Nor is processing of the new packet what you want in all cases. >>>>>>=20 >>>>>>=20 >>>>>>> If youre not comfortable with adding stuff after the BFD >>>>>> payload then we can always take up an Auth Type (say 9) which can >>>>>> then be used to carry all the other interesting stuff. >>>>>>=20 >>>>>> what has this to do with auth? This is what I name a "hack", >>>>>> sorry. It's exactly my problem, we "work around" instead of >>>>>> addressing a problem straight forward. >>>>>> (I'm not surprised you bring up auth as this is an area you = heavily >>>>>> work on ;-) >>>>>>=20 >>>>>>=20 >>>>>> Regards, Marc >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>>>> Sent: Monday, May 27, 2013 12:33 PM >>>>>>>> To: Bhatia, Manav (Manav) >>>>>>>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas >>>>>> (jhaas@juniper.net); >>>>>>>> rtg-bfd@ietf.org; Marc Binderberger >>>>>>>> Subject: Re: The "version" topic (was: Reserved = discriminators?) >>>>>>>>=20 >>>>>>>> Hello Manav, >>>>>>>>=20 >>>>>>>> all fine and good - but I really don't understand this >>>>>> avoidance of a >>>>>>>> version change while we start looking for "ways to extend" >>>>>> that all >>>>>>>> have the one or other limit. What is the problem of thinking = this >>>>>>>> straight forward: you have a change - forget "substantial" >>>>>> - or even >>>>>>>> a re-interpretation in the header, then it _is_ a new version. >>>>>>>>=20 >>>>>>>> Programming-wise this is clean, you have a well-defined = indicator >>>>>>>> that this packet needs a different treatment. >>>>>>>> Nothing to conclude, not depending on IP header length - >>>>>> BFD per se >>>>>>>> is not IP related - and the right place is really the BFD = header >>>>>>>> itself when your idea is for the many BFD usages (IP, IP-less). >>>>>>>>=20 >>>>>>>> The "backwards compatible" header I put in my last email >>>>>> was just the >>>>>>>> very few first fields. The rest may look very different. Even >>>>>>>> when the rest of the header would have the same size of an v1 >>>>>> header but I >>>>>>>> interpret them differently, then that's not v1 anymore. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, Marc >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote: >>>>>>>>=20 >>>>>>>>> Alternatively, we can use the "Authentication Present" bit >>>>>>>> in the header to carry this additional block. >>>>>>>>>=20 >>>>>>>>> Once draft-ietf-bfd-generic-crypto-auth-04 becomes a >>>>>>>> standard we will never consume any more bits in the Auth Type = as >>>>>>>> this draft introduces a Key ID mechanism. This means that Auth >>>>>>>> Type values beyond 8 are available to be used for other >>>>>>>> mechanisms. >>>>>>>>>=20 >>>>>>>>> We could for instance define value 8 meaning a BFD data >>>>>>>> block. This can then be TLV encoded. >>>>>>>>>=20 >>>>>>>>> This is again an example of how BFD can be extended while >>>>>>>> remaining completely backward compatible -- without bumping the >>>>>>>> version of BFD. >>>>>>>>>=20 >>>>>>>>> Cheers, Manav >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, >>>>>>>> Manav (Manav) >>>>>>>>>> Sent: Monday, May 27, 2013 10:07 AM >>>>>>>>>> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo) >>>>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>>>>>>>> Subject: RE: The "version" topic (was: Reserved >>>>>>>>>> discriminators?) >>>>>>>>>>=20 >>>>>>>>>> Hi Marc, >>>>>>>>>>=20 >>>>>>>>>> We usually do a version change when there is a very very >>>>>>>> substantial >>>>>>>>>> upgrade to the protocol - a kind that's usually non backward >>>>>>>>>> compatible. >>>>>>>>>>=20 >>>>>>>>>> If we really want to introduce newer fields to the packet >>>>>>>> while being >>>>>>>>>> backward compatible then the best approach imo is this: >>>>>>>>>>=20 >>>>>>>>>> You stuff whatever additional information you want in a >>>>>>>> special BFD >>>>>>>>>> data block immediately at the end of the BFD packet. >>>>>> Don't include >>>>>>>>>> the length of this additional BFD block in the BFD header. >>>>>>>> Instead, >>>>>>>>>> account for this in the IPv4/IPv6 header length. >>>>>>>>>>=20 >>>>>>>>>> +---------------------+ -- >>>>>>>>>> | IP Header | ^ >>>>>>>>>> | Length =3D HL+X+Y | | Header Length >>>>>>>>>> | | v >>>>>>>>>> +---------------------+ -- >>>>>>>>>> | BFD Header | ^ >>>>>>>>>> | Length =3D X | | >>>>>>>>>> |.....................| | X >>>>>>>>>> | | | >>>>>>>>>> | BFD Data | >>>>>>>>>> | | v >>>>>>>>>> +---------------------+ -- >>>>>>>>>> | | ^ >>>>>>>>>> | BFD Data Block | Y >>>>>>>>>> | | v >>>>>>>>>> +---------------------+ -- >>>>>>>>>>=20 >>>>>>>>>> How this additional BFD data block will be used is beyond >>>>>>>> the scope >>>>>>>>>> of the discussion right now. You could define that to be >>>>>>>> TLV encoded >>>>>>>>>> for ensuring easy extensibility. >>>>>>>>>>=20 >>>>>>>>>> Implementations can either implicitly figure out the >>>>>>>> presence of the >>>>>>>>>> BFD data block by looking at the packet lengths in the >>>>>>>> headers or can >>>>>>>>>> explicitly be indicated in the BFD header. >>>>>>>>>>=20 >>>>>>>>>> If people think it's a worthwhile idea to pursue then >>>>>> this can be >>>>>>>>>> quickly drafted. >>>>>>>>>>=20 >>>>>>>>>> Cheers, Manav >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >>>>>>>>>>> Binderberger >>>>>>>>>>> Sent: Sunday, May 26, 2013 6:49 PM >>>>>>>>>>> To: Jeffrey Haas; Nobo Akiya (nobo) >>>>>>>>>>> Cc: Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >>>>>>>>>>> Subject: The "version" topic (was: Reserved discriminators?) >>>>>>>>>>>=20 >>>>>>>>>>> Hello everyone, >>>>>>>>>>>=20 >>>>>>>>>>> sorry for me delayed response. >>>>>>>>>>>=20 >>>>>>>>>>> Taking a step back. If we would write RFC5880 today then we >>>>>>>>>> probably >>>>>>>>>>> would have reserved a small number of discriminators, e.g. >>>>>>>>>> the first 8 >>>>>>>>>>> or 16 values. But RFC5880 is since 3 years out, the >>>>>>>>>> underlying draft >>>>>>>>>>> is even much older. The statement in the Spec is >>>>>>>> effectively: dear >>>>>>>>>>> implementor, beside the zero value do what you like with >>>>>>>>>> this value. >>>>>>>>>>> We cannot claim back parts of the number space without = risking >>>>>>>>>>> problems. >>>>>>>>>>>=20 >>>>>>>>>>> This is why I tend more and more to have clean separation, >>>>>>>>>> be it a new >>>>>>>>>>> IP/UDP port like BFD-on-lags or be it a new version number. >>>>>>>>>> The latter >>>>>>>>>>> faces, I think, largely a psychological problem :-) >>>>>>>>>>>=20 >>>>>>>>>>> Independent if Nobo and me can convince this audience about >>>>>>>>>>> the redundancy concept we propose - working on it - I do see >>>>>>>>>>> more >>>>>>>>>>> (private) ideas that cover BFD sessions in a general sense, >>>>>>>>>> i.e. cover >>>>>>>>>>> the various RFCs, single-, multi-hop, with/withou label and >>>>>>>>>> so on. In >>>>>>>>>>> all cases I see people spending time to "fiddle about the >>>>>>>>>> bits" of the >>>>>>>>>>> BFD v1 and the IP header. Smart stuff but somehow crazy how >>>>>>>>>> wicked the >>>>>>>>>>> new definitions become, not to mention the difficulties for >>>>>>>>>>> implementations and for interop. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Yes, we have a limited number of versions available. >>>>>> Let me throw >>>>>>>>>>> this idea at the BFD audience: the base v2 header would >>>>>> look like >>>>>>>>>>> this: >>>>>>>>>>>=20 >>>>>>>>>>> 0 1 2 = 3 >>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >>>>>> 7 8 9 0 1 >>>>>>>>>>>=20 >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> |0 1 0| Subtype | TBD, depending on Subtype | >>>>>>>> Length | >>>>>>>>>>>=20 >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> | My Discriminator >>>>>>>> | >>>>>>>>>>>=20 >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> | Your Discriminator >>>>>>>> | >>>>>>>>>>>=20 >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> | ... >>>>>>>> | >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The subtype (the former Diag field) would allow for 32 new >>>>>>>>>>> definitions. Actually I do not hope myself we define so many >>>>>>>>>>> variations ;-) but it opens up room that we do not have >>>>>> with the >>>>>>>>>>> version field alone. >>>>>>>>>>>=20 >>>>>>>>>>> To emphasize: defining a v2 header does not mean v1 is >>>>>>>> obsolete. BFD >>>>>>>>>>> v1 works great, I'm not trying to replace it and whenever >>>>>>>> it can be >>>>>>>>>>> used it must be used. >>>>>>>>>>>=20 >>>>>>>>>>> For the other fields above, just quickly my thoughts (if >>>>>>>> we want to >>>>>>>>>>> dive deeper into this I better write a draft to discuss): >>>>>>>>>>>=20 >>>>>>>>>>> - length field remains in it's position, for ease of >>>>>>>> implementation >>>>>>>>>>>=20 >>>>>>>>>>> - of course I keep the discriminator concept - or it >>>>>>>> wouldn't be BFD >>>>>>>>>>> anymore ;-) and I keep them again at the same position >>>>>>>> (the coders >>>>>>>>>>> of NP, FPGA etc never have enough cycles or gates. And >>>>>>>> these fields >>>>>>>>>>> are used "in hardware") >>>>>>>>>>>=20 >>>>>>>>>>> - not obvious here but I would define a relatively strict >>>>>>>> upper size >>>>>>>>>>> limit. I'm not proposing a generic TLV format, based on the >>>>>>>>>>> difficulties I know about implementing really fast I/O it >>>>>>>> is better >>>>>>>>>>> to have fixed formats, IMHO. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Feedback is very welcome. And yes, I have mixed emotions >>>>>>>> myself to >>>>>>>>>>> let the genie out of the bottle :-) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>> Marc >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hello Jeff, et al, >>>>>>>>>>>>=20 >>>>>>>>>>>>> But, if the reserved value was used *only* for the context >>>>>>>>>>> of telling >>>>>>>>>>>>> the remote side "this is your redundant connection", and >>>>>>>>>>>>> some reserved value was used in Down state for Your >>>>>>>>>>> Discriminator to help >>>>>>>>>>>>> with de-multiplexing (e.g. >>>>>>>>>>>>> 1 or 0xffffffff), that would be sufficient. >>>>>>>>>>>>=20 >>>>>>>>>>>> Correct, that was my thoughts. Let's say reserved value >>>>>>>>>>> one(1) was used for shadow session bootstrapping purpose. >>>>>>>>>>> Value one(1) of shadow is equivalent of value zero(0) of >>>>>>>> primary. If >>>>>>>>>>> "your discriminator =3D=3D 1" is received on a node which >>>>>> understands >>>>>>>>>>> this, then it is to map to shadow session. >>>>>>>>>>> De-multiplex success. >>>>>>>>>>>>=20 >>>>>>>>>>>> - Benefit of the redundancy concept is seen more on >>>>>>>>>>> distributed systems or a system having at least two cards >>>>>>>>>>> (ex: 2 route processor cards) which BFD can run actively. >>>>>>>>>>>> - Benefit of the redundancy concept is also seen more on >>>>>>>>>>> those BFD sessions which aren't tied to specific physical >>>>>>>> interfaces >>>>>>>>>>> (ex: multihop, logical/virtual interfaces). >>>>>>>>>>>> - Redundancy concept is applicable to both SW and HW based >> BFD. >>>>>>>>>>>>=20 >>>>>>>>>>>> Scope of use case has limitations, in terms of system >>>>>>>>>>> architecture as well as BFD type, but for those that >>>>>> this applies >>>>>>>>>>> to, I still do see great benefits. >>>>>>>>>>>>=20 >>>>>>>>>>>>> We still have a possibility of colliding with existing >>>>>>>>>> sessions if >>>>>>>>>>>>> the remote side makes use of the reserved value. Bumping >>>>>>>>>>> the version >>>>>>>>>>>>> number is an obvious fix but if we're going to that extent >>>>>>>>>>> we need to >>>>>>>>>>>>> think more carefully about the full work we'd want under >>>>>>>>>>> such a rev. >>>>>>>>>>>>=20 >>>>>>>>>>>> I still do not see any implementations which cannot support >>>>>>>>>>> few more reserved discriminators. But a node speaking >>>>>> to another >>>>>>>>>>> which doesn't support added reserved discriminator range can >>>>>>>>>>> certainly cause undesired collision. And I agree that >>>>>> bumping the >>>>>>>>>>> version number would solve this easily. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Nobo >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>=20 >=20 >=20 >=20