From rtg-bfd-bounces@ietf.org Thu Jan 03 14:11:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVTZ-0007CD-Jt; Thu, 03 Jan 2008 14:11:33 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JAVTX-0007C8-W8 for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 14:11:31 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JAVTX-0007C0-Mj for rtg-bfd@ietf.org; Thu, 03 Jan 2008 14:11:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVRw-0006N9-Ie for rtg-bfd@ietf.org; Thu, 03 Jan 2008 14:09:52 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAVRw-0005Go-5Q for rtg-bfd@ietf.org; Thu, 03 Jan 2008 14:09:52 -0500 Received: by nf-out-0910.google.com with SMTP id d21so409230nfb.39 for ; Thu, 03 Jan 2008 11:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=glMJozD1t05P7qx/3A/foMKj1dEkPEK54s1kAOxjMH0=; b=i/ekyslTLgB2l4riSE2C22G7JaZZR4cymrkb5LrVCRQzutf42/D6ny0xz+jDsILGWFv+8+g/7q8NOlhYwY4DJaUzQ6q/jLXg9vJBYhMdCn78Tvr4yIug3Eb65gzVQ/nrIgvMiqdmTUHIW9vqRswy0gfdnehRUkfDp//dXp+EUmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=DAGbjx+7AwZrnMCWwmWifPW8VdnqkpiZgivub9mfi6eiKreecNePZhOKrfUBKlfFtUSWkeEw8ApItmpYfaty0XmC6d4Ra7Ceduobuqq1FI3IGyl4gQHFb543s20on4u5uJWpeSRHdSIOrALvsyvwx+KXuNmr/Bd04bcd6vvlNAg= Received: by 10.78.122.16 with SMTP id u16mr18669352huc.28.1199387390599; Thu, 03 Jan 2008 11:09:50 -0800 (PST) Received: by 10.78.118.4 with HTTP; Thu, 3 Jan 2008 11:09:50 -0800 (PST) Message-ID: <3b958f170801031109ld16515axa50f46c0245dc29c@mail.gmail.com> Date: Fri, 4 Jan 2008 00:39:50 +0530 From: "Sriram K" To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27301_18210455.1199387390592" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-TMDA-Confirmed: Thu, 03 Jan 2008 14:11:31 -0500 Subject: Destination port of BFD Control packet from Egress LSR in BFD-MPLS X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------=_Part_27301_18210455.1199387390592 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Section 7 of [BFD-MPLS] states that "BFD control packets sent by the egress LSR are UDP packets. The source IP address is a routable address of the replier; the source port is the well-known UDP port 3784. The destination IP address and UDP port MUST be copied from the source IP address and UDP port of the control packet received from the ingress LSR." Section 5 of [BFD-MPLS] states that "On receipt of the LSP-Ping echo request message, the egress LSR MUST send a BFD control packet to the ingress LSR." What would be the UDP destination port of the first BFD Control packet that the Egress LSR transmits after receiving the LSP-Ping echo request message? The destination UDP port will be unknown until a BFD Control Packet is received from the Ingress LSR. Will the packet be transmitted with the source and destination UDP port as 3784 till a BFD Control packet is received from the Ingress LSR, after which the source UDP port is copied in to the destination UDP port. Or Am I missing some thing? -- Thanks & Regards, Sriram K ------=_Part_27301_18210455.1199387390592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Section 7 of [BFD-MPLS] states that

   "BFD control packets sent by the egress LSR are UDP packets. The
   source IP address is a routable address of the replier; the source
   port is the well-known UDP port 3784.  The destination IP address and
   UDP port MUST be copied from the source IP address and UDP port of
   the control packet received from the ingress LSR."

Section 5 of [BFD-MPLS] states that

   "On receipt of the LSP-Ping echo request message, the egress LSR MUST
   send a BFD control packet to the ingress LSR."

What would be the UDP destination port of the first BFD Control packet  that the
Egress LSR transmits after receiving the LSP-Ping echo request message? The
destination UDP port will be unknown until a BFD Control Packet is received from
the Ingress LSR.

Will the packet be transmitted with the source and destination UDP port as 3784
till a BFD Control packet is received from the Ingress LSR, after which the source
UDP port is copied in to the destination UDP port. Or Am I missing some thing?

--
Thanks & Regards,
Sriram K ------=_Part_27301_18210455.1199387390592-- From rtg-bfd-bounces@ietf.org Tue Jan 08 12:17:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI4T-0008TD-69; Tue, 08 Jan 2008 12:17:01 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JCI4S-0008T4-Mm for rtg-bfd-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:17:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI4S-0008SC-AI for rtg-bfd@ietf.org; Tue, 08 Jan 2008 12:17:00 -0500 Received: from fncnmp04.fnc.fujitsu.com ([168.127.0.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCI4R-0000MG-Kk for rtg-bfd@ietf.org; Tue, 08 Jan 2008 12:17:00 -0500 X-IronPort-AV: E=Sophos;i="4.24,258,1196661600"; d="scan'208,217";a="190385266" Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp02.fnc.fujitsu.com with ESMTP; 08 Jan 2008 11:16:49 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8521A.3F431A0D" Date: Tue, 8 Jan 2008 11:16:45 -0600 Message-ID: In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252E22C@ilptex01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Technical Issues + Delay + T-MPLS OAM Thread-Index: AchGRWJTSg9Tp6rsQYSoOWe3rMC00wL0V0Mw References: <64122293A6365B4A9794DC5636F9ACFD0252E22C@ilptex01.ecitele.com> From: "O'Connor, Don" To: "Alexander Vainshtein" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: rcallon@juniper.net, rtg-bfd@ietf.org, Alik Shimelmits Subject: BFD Technical Issues + Delay + T-MPLS OAM X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8521A.3F431A0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, Jeffrey, Ross, and all =20 What are the unresolved technical issues with BFD that are resulting in such a long delay in progressing the drafts and holding meetings? Can you please socialize these issues with the email list so that everybody is aware of the issues in detail?=20 =20 I see a lot of effort being devoted to T-MPLS OAM. What about finishing BFD? =20 Regards =20 Don =20 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, December 24, 2007 9:55 AM To: dward@cisco.com; jhaas@prfc.org Cc: rtg-bfd@ietf.org; Alik Shimelmits Subject: What is the status of the WG documents? =20 Dave, Jeffrey and all, I have missed the Vancouver IETF meeting, and I would like to know what happens to the WG drafts. =20 At the Prague meeting they have been declared as ready for the WG LC, but, AFAIK, it has never been declared. And most of the drafts have now expired. =20 Any info will be highly appreciated. =20 Regards, Sasha Vainshtein ------_=_NextPart_001_01C8521A.3F431A0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave, Jeffrey, Ross, and = all

 

What are the unresolved technical = issues with BFD that are resulting in such a long delay in progressing the = drafts and holding meetings? Can you please socialize these issues with the email = list so that everybody is aware of the issues in detail? =

 

I see a lot of effort being devoted = to T-MPLS OAM. What about finishing BFD?

 

Regards

=

 

Don

 

From: = Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, December = 24, 2007 9:55 AM
To: dward@cisco.com; jhaas@prfc.org
Cc: rtg-bfd@ietf.org; = Alik Shimelmits
Subject: What is the = status of the WG documents?

 

Dave, Jeffrey and all,

I have missed the Vancouver IETF meeting, and I would = like to know what happens to the WG drafts.

 

At the Prague meeting they have been declared as ready for the WG LC, but, AFAIK, it = has never been declared.

And most of the drafts have now = expired.

 

Any info will be highly = appreciated.

 

Regards,

         =      Sasha Vainshtein

------_=_NextPart_001_01C8521A.3F431A0D-- From rtg-bfd-bounces@ietf.org Thu Jan 10 15:42:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD4EH-0000gg-Cz; Thu, 10 Jan 2008 15:42:21 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD4EF-0000gN-Ls for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 15:42:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD4EF-0000gC-A5 for rtg-bfd@ietf.org; Thu, 10 Jan 2008 15:42:19 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD4EE-0004bh-EK for rtg-bfd@ietf.org; Thu, 10 Jan 2008 15:42:19 -0500 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 10 Jan 2008 22:59:48 +0200 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jan 2008 22:42:13 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.240.5; Thu, 10 Jan 2008 22:42:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C853C9.4745A9C0" Date: Thu, 10 Jan 2008 22:42:12 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchTxJoMy3m6iHfxTVCQbsdfBl6XpA== X-Priority: 1 Priority: Urgent Importance: high From: Alexander Vainshtein To: "David Ward" , "David Katz" X-OriginalArrivalTime: 10 Jan 2008 20:42:13.0849 (UTC) FILETIME=[47D14C90:01C853C9] X-Spam-Score: 1.8 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Ronen Sommer , BFD WG , Igor Danilovich Subject: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------_=_NextPart_001_01C853C9.4745A9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have a question related to the expected behavior of sequence numbers = in an aythenticated (MD5 or SHA1) BFD session. =20 The corresdponding sections of draft-ietf-bfd-base-06 state that, once = the packet has been authenticated by the receiver, its sequence number = MUST be checked; if its value is out of range defined by the last = received sequence number and the Detect Multiplexor, the packet MUST be = discarded. =20 This may result in the a BFD session going down in the situation when = the transceiver "loses" the information about its last transmitted = sequence number. A suitable use case is a multilink interface (LAG, = ML-PPP, etc.) with the links residing in different line cards, and e BFD = implemented in one of these cards: if this card fails, the BFD would = could be re-started in one of the remaining cards. Such a restart would = not affect the local session because the BFD machine would be restarted = with bfd.AuthSeqKnown =3D 0, but keeping bfd.XmitAuthSeq consistent = between different line cards seems problematic. (Implemeting BFD in some = common card would resolve the situation with the multilink interfaces = but would raise similar issues when the common card fails). =20 Note that this problem would not occur for a non-authenticated BFD = session. =20 IMHO this problem is real, and I do not see a simple solution for it.=20 I would highly appreciate any feedback from the draft authors and/or = from the WG. =20 Regards, Sasha =20 ------_=_NextPart_001_01C853C9.4745A9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
Hi all,
=0A=
I have a question related to the = expected behavior of sequence numbers in an aythenticated (MD5 or SHA1) = BFD session.
=0A=
 
=0A=
The corresdponding sections of = draft-ietf-bfd-base-06 state that, once the packet has been = authenticated by the receiver, its sequence number MUST be checked; if = its value is out of range defined by the last received sequence number = and the Detect Multiplexor, the packet MUST be discarded.
=0A=
 
=0A=
This may result in the a BFD session = going down in the situation when the transceiver "loses" the information = about its last transmitted sequence number. A suitable use = case is a multilink interface (LAG, ML-PPP, etc.) with the links = residing in different line cards, and e BFD implemented in one = of these cards: if this card fails, the BFD would could = be re-started in one of the remaining cards. Such a restart would not = affect the local session because the BFD machine = would be restarted with bfd.AuthSeqKnown =3D 0, but = keeping bfd.XmitAuthSeq consistent between different = line cards seems problematic. (Implemeting BFD in some common card would = resolve the situation with the multilink interfaces but would raise = similar issues when the common card fails).
=0A=
 
=0A=
Note that this problem would not = occur for a non-authenticated BFD session.
=0A=
 
=0A=
IMHO this problem is real, and I do not = see a simple solution for it. 
=0A=
I would highly appreciate any feedback = from the draft authors and/or from the WG.
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;       Sasha
=0A=
 
------_=_NextPart_001_01C853C9.4745A9C0-- From rtg-bfd-bounces@ietf.org Thu Jan 10 16:42:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5AY-0003Xj-LI; Thu, 10 Jan 2008 16:42:34 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD5AX-0003Xe-Bz for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 16:42:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5AW-0003XW-Vv for rtg-bfd@ietf.org; Thu, 10 Jan 2008 16:42:33 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD5AV-0005lz-U1 for rtg-bfd@ietf.org; Thu, 10 Jan 2008 16:42:32 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jan 2008 13:41:45 PST Received: from emailcorp1.jnpr.net ([66.129.254.11]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 13:41:24 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 13:41:16 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C853D1.86AF95EB" Date: Thu, 10 Jan 2008 13:41:15 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchTxJoMy3m6iHfxTVCQbsdfBl6XpAAC7lpQ References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> From: "Nitin Bahadur" To: "Alexander Vainshtein" , "David Ward" , "Dave Katz" X-OriginalArrivalTime: 10 Jan 2008 21:41:16.0231 (UTC) FILETIME=[873DE570:01C853D1] X-Spam-Score: 0.6 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: BFD WG , Ronen Sommer , Igor Danilovich Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C853D1.86AF95EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alexander, =20 I agree that keeping the sequence number consistent between line cards is not practical. We need a way for a system to indicate that it wants to restart the sequence. =20 Nitin =20 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, January 10, 2008 12:42 PM To: David Ward; Dave Katz Cc: Ronen Sommer; BFD WG; Igor Danilovich Subject: Resetting the sequence number in an authenticated BFD session Importance: High =20 Hi all, I have a question related to the expected behavior of sequence numbers in an aythenticated (MD5 or SHA1) BFD session. =20 The corresdponding sections of draft-ietf-bfd-base-06 state that, once the packet has been authenticated by the receiver, its sequence number MUST be checked; if its value is out of range defined by the last received sequence number and the Detect Multiplexor, the packet MUST be discarded. =20 This may result in the a BFD session going down in the situation when the transceiver "loses" the information about its last transmitted sequence number. A suitable use case is a multilink interface (LAG, ML-PPP, etc.) with the links residing in different line cards, and e BFD implemented in one of these cards: if this card fails, the BFD would could be re-started in one of the remaining cards. Such a restart would not affect the local session because the BFD machine would be restarted with bfd.AuthSeqKnown =3D 0, but keeping bfd.XmitAuthSeq consistent between different line cards seems problematic. (Implemeting BFD in some common card would resolve the situation with the multilink interfaces but would raise similar issues when the common card fails). =20 Note that this problem would not occur for a non-authenticated BFD session. =20 IMHO this problem is real, and I do not see a simple solution for it.=20 I would highly appreciate any feedback from the draft authors and/or from the WG. =20 Regards, Sasha =20 ------_=_NextPart_001_01C853D1.86AF95EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alexander,

 

   I agree that keeping the = sequence number consistent between line = cards is not practical. We need a way for a system to indicate that it wants to = restart the sequence.

 

Nitin

 

From: = Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, January = 10, 2008 12:42 PM
To: David Ward; = Dave Katz
Cc: Ronen Sommer; BFD WG; = Igor Danilovich
Subject: = Resetting the sequence number in an authenticated BFD session
Importance: = High

 

Hi = all,

I have a question related to the expected behavior of = sequence numbers in an aythenticated (MD5 = or SHA1) BFD session.

 

The corresdponding sections of draft-ietf-bfd-base-06 = state that, once the packet has been authenticated by the receiver, its = sequence number MUST be checked; if its = value is out of range defined by the last received sequence number and the Detect Multiplexor, the packet MUST be = discarded.

 

This may result in the a BFD session going down in the situation when the transceiver "loses" the information about its last transmitted sequence number. A suitable use = case is a multilink interface (LAG, = ML-PPP, etc.) with the links residing in different line cards, and e BFD implemented in one of these cards: if this card fails, the BFD would could be = re-started in one of the remaining cards. Such a restart would not affect the = local session because the BFD machine would be restarted with = bfd.AuthSeqKnown =3D = 0, but keeping bfd.XmitAuthSeq consistent between different line cards seems problematic. (Implemeting BFD in some common card would resolve the = situation with the multilink interfaces but would raise similar issues when the common card fails).

 

Note that this problem would not occur for a non-authenticated BFD session.

 

IMHO this problem is real, and I do not = see a simple solution for = it. 

I would highly appreciate any feedback from the draft authors and/or from the WG.

 

Regards,

         =          Sasha

 

------_=_NextPart_001_01C853D1.86AF95EB-- From rtg-bfd-bounces@ietf.org Thu Jan 10 17:11:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5cu-0006bO-09; Thu, 10 Jan 2008 17:11:52 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD5cs-0006bJ-SM for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 17:11:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5cs-0006bA-Es for rtg-bfd@ietf.org; Thu, 10 Jan 2008 17:11:50 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD5cr-0006He-Ct for rtg-bfd@ietf.org; Thu, 10 Jan 2008 17:11:50 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jan 2008 14:11:45 PST Received: from emailcorp2.jnpr.net ([66.129.254.12]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 14:11:41 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 14:10:51 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C853D5.A8C7B3A3" Date: Thu, 10 Jan 2008 14:10:50 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchT0vfa1VyobG3RSpWwPFWe+pDrkAAAV0cg References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> From: "Nitin Bahadur" To: "David Ward" X-OriginalArrivalTime: 10 Jan 2008 22:10:51.0057 (UTC) FILETIME=[A91EDA10:01C853D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0fa531afcd551ff81145d3275aa425e Cc: Ronen Sommer , BFD WG , Igor Danilovich , Dave Katz Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C853D5.A8C7B3A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's not sufficient from a practical point of view. Here's why. =20 * run BFD on bundled interfaces (any flavor) centrally Can't support very low detection times. Only line cards can support tens of ms. =20 * run BFD on all component links independently This solution does not work for multi-hop bfd sessions. If the outgoing link for a mhop session is a link-bundle, then you would need to create a 1 session per component link just to monitor the health of a single bfd peer. Also, for a mhop session, if there are link bundles on both the peers, I'm not sure how it would work. =20 * run BFD on a master component link What if the master goes down? The link is still UP. If you now assign the master to a different line card, you end up with problem of sequence number out of sync. =20 I would be interested in knowing the other variants that might help solve the above issues. =20 Thanks Nitin =20 ________________________________ From: David Ward [mailto:dward@cisco.com]=20 Sent: Thursday, January 10, 2008 1:51 PM To: Nitin Bahadur Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD session =20 Solutions include (and are alluded to in the drafts): =20 run BFD on bundled interfaces (any flavor) centrally run BFD on all component links independently run BFD on a master component link =20 There are other variants as well. =20 -DWard =20 On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: Alexander, =20 I agree that keeping the sequence number consistent between line cards is not practical. We need a way for a system to indicate that it wants to restart the sequence. =20 Nitin =20 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, January 10, 2008 12:42 PM To: David Ward; Dave Katz Cc: Ronen Sommer; BFD WG; Igor Danilovich Subject: Resetting the sequence number in an authenticated BFD session Importance: High =20 Hi all, I have a question related to the expected behavior of sequence numbers in an aythenticated (MD5 or SHA1) BFD session. =20 The corresdponding sections of draft-ietf-bfd-base-06 state that, once the packet has been authenticated by the receiver, its sequence number MUST be checked; if its value is out of range defined by the last received sequence number and the Detect Multiplexor, the packet MUST be discarded. =20 This may result in the a BFD session going down in the situation when the transceiver "loses" the information about its last transmitted sequence number. A suitable use case is a multilink interface (LAG, ML-PPP, etc.) with the links residing in different line cards, and e BFD implemented in one of these cards: if this card fails, the BFD would could be re-started in one of the remaining cards. Such a restart would not affect the local session because the BFD machine would be restarted with bfd.AuthSeqKnown =3D 0, but keeping bfd.XmitAuthSeq consistent between different line cards seems problematic. (Implemeting BFD in some common card would resolve the situation with the multilink interfaces but would raise similar issues when the common card fails). =20 Note that this problem would not occur for a non-authenticated BFD session. =20 IMHO this problem is real, and I do not see a simple solution for it.=20 I would highly appreciate any feedback from the draft authors and/or from the WG. =20 Regards, Sasha =20 =20 ------_=_NextPart_001_01C853D5.A8C7B3A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s not sufficient from a practical point of view. Here’s why.

 

Ø      = run BFD on bundled interfaces (any flavor) centrally

Can’t support very low detection times. = Only line cards can support tens of ms.

 

Ø      = run BFD on all component links independently

This solution does not work for multi-hop bfd = sessions. If the outgoing link for a mhop = session is a link-bundle, then you would = need to create a 1 session per = component link just to monitor the health of a single bfd peer. Also, for a mhop = session, if there are link bundles on both = the peers, I’m not sure how it would = work.

 

Ø      = run BFD on a master component link

What if the master goes down? The link is = still UP. If you now assign the master to a different line card, you end up with = problem of sequence number out of = sync.

 

I would be interested in knowing = the other variants that might help solve the above = issues.

 

Thanks

Nitin

 

From: David = Ward [mailto:dward@cisco.com]
Sent: Thursday, January = 10, 2008 1:51 PM
To: Nitin Bahadur
Cc: David Ward; Alexander Vainshtein; Dave Katz; = Ronen Sommer; BFD WG; Igor Danilovich
Subject: Re: = Resetting the sequence number in an authenticated BFD session

 

Solutions include (and are alluded to in the = drafts):

 

run BFD on bundled interfaces (any flavor) = centrally

run BFD on all component links = independently

run BFD on a master component link

 

There are other variants as well.

 

-DWard

 

On Jan 10, 2008, at 3:41 PM, Nitin = Bahadur wrote:



Alexander,

 <= font color=3Dblack>

   I agree that keeping = the sequence number consistent = between line cards is not practical. We need a way for a system to indicate that = it wants to restart the sequence.

 <= font color=3Dblack>

Nitin

 

From: Alexander Vainshtein [mailto:Alexander.Vainsht= ein@ecitele.com] 
Sent: Thursday, January 10, 2008 = 12:42 PM
To: David Ward; Dave Katz
Cc: Ronen Sommer; BFD WG; Igor = Danilovich
Subject: Resetting the sequence number in an = authenticated BFD session
Importance: High

 

Hi all,

I have a question related to the = expected behavior of sequence numbers in an aythenticated (MD5 or SHA1) BFD session.

 

The corresdponding sections of = draft-ietf-bfd-base-06 state that, once the = packet has been authenticated by the receiver, its sequence number MUST be = checked; if its value is out of range defined by the last received sequence number and the = Detect Multiplexor, the packet MUST be discarded.

 

This may result in the a BFD session going down in the = situation when the transceiver "loses" the information about its last transmitted sequence number. A = suitable use case is a multilink = interface (LAG, ML-PPP, etc.) with the links residing in = different line cards, and e BFD implemented in one of these cards: if this = card fails, the BFD would could be re-started in one of the remaining cards. = Such a restart would not affect the local session = because the = BFD machine would be restarted with bfd.AuthSeqKnown =3D 0, but = keeping bfd.XmitAuthSeq consistent between different = line cards seems problematic. = (Implemeting BFD in some common card would resolve the situation with the multilink = interfaces but would raise similar issues when the = common card fails).

 

Note that this problem would not occur for a non-authenticated BFD session.

 

IMHO this problem is real, and I = do not see a simple solution for = it. 

I would highly appreciate any = feedback from the draft authors and/or from the WG.

 

Regards,

      = ;            Sasha

 

 

------_=_NextPart_001_01C853D5.A8C7B3A3-- From rtg-bfd-bounces@ietf.org Thu Jan 10 17:20:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5kn-00063Y-UR; Thu, 10 Jan 2008 17:20:01 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD5kn-00062z-1j for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 17:20:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5km-00062h-Ju for rtg-bfd@ietf.org; Thu, 10 Jan 2008 17:20:00 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD5kl-0006Rs-1H for rtg-bfd@ietf.org; Thu, 10 Jan 2008 17:20:00 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2008 17:19:59 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0AMJwv9004759; Thu, 10 Jan 2008 17:19:58 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0AMJo6n021002; Thu, 10 Jan 2008 22:19:54 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 17:19:52 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 17:19:51 -0500 In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: multipart/alternative; boundary=Apple-Mail-6-505565664 Message-Id: From: David Ward Date: Thu, 10 Jan 2008 16:19:41 -0600 To: "Nitin Bahadur" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 10 Jan 2008 22:19:52.0043 (UTC) FILETIME=[EB92C3B0:01C853D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=38904; t=1200003598; x=1200867598; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20Resetting=20the=20sequence=20number=20i n=20an=20authenticated=20BFD=20session |Sender:=20 |To:=20=22Nitin=20Bahadur=22=20; bh=osnSRkzk0zkP/YWTbyH88NVeU/kYCTXRWoPq8ClpOKw=; b=xmPln6kUB3aUAoLhK/VYUKQvZOzK13XqcYT5vmNE24AJepFdJNv2g/WPpO AYWEbp+aEvEQhaYg4NDadJpOsWpb3NJMgEQ6P5Rs7gX+H95l+q7LcJlDtNWJ MmnOf3fObR; Authentication-Results: rtp-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: ad21aece51aeebf80192250df67eab8a Cc: Ronen Sommer , Dave Katz , Igor Danilovich , David Ward , BFD WG Subject: Re: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-6-505565664 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Nitin - inline On Jan 10, 2008, at 4:10 PM, Nitin Bahadur wrote: > That=92s not sufficient from a practical point of view. Here=92s why. > > =D8 run BFD on bundled interfaces (any flavor) centrally > Can=92t support very low detection times. Only line cards can support =20= > tens of ms. > > =D8 run BFD on all component links independently > This solution does not work for multi-hop bfd sessions. If the =20 > outgoing link for a mhop session is a link-bundle, then you would =20 > need to create a 1 session per component link just to monitor the =20 > health of a single bfd peer. Also, for a mhop session, if there are =20= > link bundles on both the peers, I=92m not sure how it would work. > DW: The picture would be that the component links in an L2 bundle are =20= directly adjacent. In an L2 bundle situation where you want to test =20 each link independently with bidir comms between two routers why =20 would it be mhop? MHop session are for those w/o being directly =20 adjacent. > =D8 run BFD on a master component link > What if the master goes down? The link is still UP. If you now =20 > assign the master to a different line card, you end up with problem =20= > of sequence number out of sync. > > I would be interested in knowing the other variants that might help =20= > solve the above issues. DW: Many of them do not require modifications to the protocol to be =20 interoperable and would be outside the scope of the BFD specification. -DWard > > Thanks > Nitin > > From: David Ward [mailto:dward@cisco.com] > Sent: Thursday, January 10, 2008 1:51 PM > To: Nitin Bahadur > Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD =20 > WG; Igor Danilovich > Subject: Re: Resetting the sequence number in an authenticated BFD =20 > session > > Solutions include (and are alluded to in the drafts): > > run BFD on bundled interfaces (any flavor) centrally > run BFD on all component links independently > run BFD on a master component link > > There are other variants as well. > > -DWard > > On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: > > > Alexander, > > I agree that keeping the sequence number consistent between line =20= > cards is not practical. We need a way for a system to indicate that =20= > it wants to restart the sequence. > > Nitin > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, January 10, 2008 12:42 PM > To: David Ward; Dave Katz > Cc: Ronen Sommer; BFD WG; Igor Danilovich > Subject: Resetting the sequence number in an authenticated BFD session > Importance: High > > Hi all, > I have a question related to the expected behavior of sequence =20 > numbers in an aythenticated (MD5 or SHA1) BFD session. > > The corresdponding sections of draft-ietf-bfd-base-06 state that, =20 > once the packet has been authenticated by the receiver, its =20 > sequence number MUST be checked; if its value is out of range =20 > defined by the last received sequence number and the Detect =20 > Multiplexor, the packet MUST be discarded. > > This may result in the a BFD session going down in the situation =20 > when the transceiver "loses" the information about its last =20 > transmitted sequence number. A suitable use case is a multilink =20 > interface (LAG, ML-PPP, etc.) with the links residing in different =20 > line cards, and e BFD implemented in one of these cards: if this =20 > card fails, the BFD would could be re-started in one of the =20 > remaining cards. Such a restart would not affect the local session =20 > because the BFD machine would be restarted with bfd.AuthSeqKnown =3D =20= > 0, but keeping bfd.XmitAuthSeq consistent between different line =20 > cards seems problematic. (Implemeting BFD in some common card would =20= > resolve the situation with the multilink interfaces but would raise =20= > similar issues when the common card fails). > > Note that this problem would not occur for a non-authenticated BFD =20 > session. > > IMHO this problem is real, and I do not see a simple solution for it. > I would highly appreciate any feedback from the draft authors and/=20 > or from the WG. > > Regards, > Sasha > > --Apple-Mail-6-505565664 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252

Nitin = -

inline

On= Jan 10, 2008, at 4:10 PM, Nitin Bahadur wrote:

That=92s not sufficient from a = practical point of view. Here=92s = why.
=A0
=D8=A0=A0=A0=A0=A0=A0run BFD on bundled interfaces (any flavor) = centrally
Can=92t support very low = detection times. Only line cards can support tens of = ms.
=D8=A0=A0=A0=A0=A0=A0run BFD on all component links independently
This solution does not work for multi-hop = bfd=A0sessions. If the outgoing link for a = mhop=A0session is a link-bundle, then you would = need to create a 1=A0session per component link just to monitor = the health of a single bfd peer. Also, for a mhop=A0session, if there are link bundles on both = the peers, I=92m not sure how it would = work.

DW: The picture would be = that the component links in an L2 bundle are directly adjacent. =A0In an = L2 bundle situation where you want to test each link =A0independently = with bidir comms between two routers why would it be mhop? MHop session = are for those w/o being directly adjacent.



=D8=A0=A0=A0=A0=A0=A0run BFD on a master component link
What if the master goes down? The link is = still UP. If you now assign the master to a different line card, you end = up with problem of=A0sequence number out of = sync.
=A0
I would be interested in knowing the = other variants that might help solve the above = issues.

DW: Many of them do not = require modifications to the protocol to be interoperable and would be = outside the scope of the BFD specification.

-DWard

=A0
Nitin
From:=A0David Ward [mailto:dward@cisco.com]=A0
Sent:=A0Thursday, January 10, 2008 = 1:51 PM
To:=A0Nitin Bahadur
Cc:=A0David Ward; Alexander = Vainshtein;=A0Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
=A0Re: = Resetting the=A0sequence number in an authenticated = BFD=A0session
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman'; ">=A0
Solutions include (and are alluded to in the = drafts):
run BFD on = bundled interfaces (any flavor) = centrally
run BFD on all component links = independently
run BFD on a master component = link
There are = other variants as well.
On Jan 10, = 2008, at 3:41 PM,=A0Nitin Bahadur=A0wrote:<= /div>
=A0=A0=A0 I agree that keeping = the=A0sequence number consistent between line = cards is not practical. We need a way for a system to indicate that it = wants to restart the=A0sequence.=A0
=A0Alexander Vainshtein [=A0
Sent:=A0Thursday, January 10, 2008 = 12:42 PM
To:=A0David Ward;=A0Dave = Katz
=A0Ronen = Sommer; BFD WG; Igor Danilovich
=A0Resetting the=A0sequence number in an authenticated = BFD=A0session
Importance:=A0HighHi = all,I have a = question related to the expected behavior of=A0sequence numbers in an aythenticated (MD5 = or SHA1) BFD=A0session.The = corresdponding=A0sections of = draft-ietf-bfd-base-06 state that, once the = packet has been authenticated by the receiver, its=A0sequence number MUST be checked; if its = value is out of range defined by the last received=A0sequence number and the Detect Multiplexor, = the packet MUST be discarded.This may = result in the a BFD=A0session going down in the situation when = the transceiver "loses" the information about = its last transmitted=A0sequence number. A = suitable=A0use=A0case=A0is a multilink = interface (LAG, ML-PPP, etc.) with the links residing in = different=A0line=A0cards, and e BFD implemented in one of = these=A0cards:=A0if this card=A0fails, = the BFD would=A0could be re-started in one of the remaining cards. Such = a restart would not affect the local=A0session = because=A0the BFD=A0machine = would=A0be restarted with=A0=A0=3D = 0, but keeping=A0=A0consistent between different = line cards=A0seems problematic. (Implemeting BFD in some = common card would resolve the situation with the multilink interfaces = but would raise=A0similar issues when the common = card fails).Note that = this problem would not occur=A0for a non-authenticated BFD=A0session.IMHO this = problem is real, and I do not=A0see a simple solution for = it.=A0I would = highly appreciate any feedback from the draft authors and/or from the = WG. References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: multipart/alternative; boundary=Apple-Mail-7-505866687 Message-Id: <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com> From: David Ward Date: Thu, 10 Jan 2008 16:24:42 -0600 To: David Ward X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 10 Jan 2008 22:24:54.0058 (UTC) FILETIME=[9F9698A0:01C853D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=40960; t=1200003902; x=1200867902; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20Resetting=20the=20sequence=20number=20i n=20an=20authenticated=20BFD=20session |Sender:=20; bh=r8KYBL1ai2Z3psvaB73cnUXf6cHUpM8Kro4c2WUG49s=; b=vWSAkrzLUYU4QmrOXETg++xxq3xK9ddLv4tpRRHiHiBSFECWvllcEpOyVA Ny9+YWR816GPhPZ+BLu2oAv1tvi7Hzi7FK2ifZ+yFAkzDC/C4BV81Zrb9Ymo G4VD+u5Xv4; Authentication-Results: sj-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: c6d4566aad1fef50f784fa8a77ccada7 Cc: Ronen Sommer , Dave Katz , Igor Danilovich , BFD WG Subject: Re: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-7-505866687 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Nitin - On Jan 10, 2008, at 4:19 PM, David Ward wrote: > > Nitin - > > inline > > On Jan 10, 2008, at 4:10 PM, Nitin Bahadur wrote: > >> That=92s not sufficient from a practical point of view. Here=92s why. >> >> =D8 run BFD on bundled interfaces (any flavor) centrally >> Can=92t support very low detection times. Only line cards can =20 >> support tens of ms. >> >> =D8 run BFD on all component links independently >> This solution does not work for multi-hop bfd sessions. If the =20 >> outgoing link for a mhop session is a link-bundle, then you would =20 >> need to create a 1 session per component link just to monitor the =20 >> health of a single bfd peer. Also, for a mhop session, if there =20 >> are link bundles on both the peers, I=92m not sure how it would work. >> > > > DW: The picture would be that the component links in an L2 bundle =20 > are directly adjacent. In an L2 bundle situation where you want to =20= > test each link independently with bidir comms between two routers =20 > why would it be mhop? MHop session are for those w/o being directly =20= > adjacent. > > DW: Perhaps you meant that two routers running a mhop BFD session =20 that traversed a link bundle somewhere inbetween. In this case there =20 is nothing you can do as there is nothing you can to to guarantee you =20= are going to traverse the same component links of the bundle =20 inbetween two other routers. The forwarding choice of how to balance =20 those flows over the component links is a local decision that the =20 mhop BFD'ing routers cannot bias. I wasn't sure if you were thinking of that case. -DWard > >> =D8 run BFD on a master component link >> What if the master goes down? The link is still UP. If you now =20 >> assign the master to a different line card, you end up with =20 >> problem of sequence number out of sync. >> >> I would be interested in knowing the other variants that might =20 >> help solve the above issues. > > > DW: Many of them do not require modifications to the protocol to be =20= > interoperable and would be outside the scope of the BFD specification. > > -DWard > >> >> Thanks >> Nitin >> >> From: David Ward [mailto:dward@cisco.com] >> Sent: Thursday, January 10, 2008 1:51 PM >> To: Nitin Bahadur >> Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD =20= >> WG; Igor Danilovich >> Subject: Re: Resetting the sequence number in an authenticated BFD =20= >> session >> >> Solutions include (and are alluded to in the drafts): >> >> run BFD on bundled interfaces (any flavor) centrally >> run BFD on all component links independently >> run BFD on a master component link >> >> There are other variants as well. >> >> -DWard >> >> On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: >> >> >> Alexander, >> >> I agree that keeping the sequence number consistent between =20 >> line cards is not practical. We need a way for a system to =20 >> indicate that it wants to restart the sequence. >> >> Nitin >> >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Thursday, January 10, 2008 12:42 PM >> To: David Ward; Dave Katz >> Cc: Ronen Sommer; BFD WG; Igor Danilovich >> Subject: Resetting the sequence number in an authenticated BFD =20 >> session >> Importance: High >> >> Hi all, >> I have a question related to the expected behavior of sequence =20 >> numbers in an aythenticated (MD5 or SHA1) BFD session. >> >> The corresdponding sections of draft-ietf-bfd-base-06 state that, =20 >> once the packet has been authenticated by the receiver, its =20 >> sequence number MUST be checked; if its value is out of range =20 >> defined by the last received sequence number and the Detect =20 >> Multiplexor, the packet MUST be discarded. >> >> This may result in the a BFD session going down in the situation =20 >> when the transceiver "loses" the information about its last =20 >> transmitted sequence number. A suitable use case is a multilink =20 >> interface (LAG, ML-PPP, etc.) with the links residing in different =20= >> line cards, and e BFD implemented in one of these cards: if this =20 >> card fails, the BFD would could be re-started in one of the =20 >> remaining cards. Such a restart would not affect the local session =20= >> because the BFD machine would be restarted with bfd.AuthSeqKnown =3D =20= >> 0, but keeping bfd.XmitAuthSeq consistent between different line =20 >> cards seems problematic. (Implemeting BFD in some common card =20 >> would resolve the situation with the multilink interfaces but =20 >> would raise similar issues when the common card fails). >> >> Note that this problem would not occur for a non-authenticated BFD =20= >> session. >> >> IMHO this problem is real, and I do not see a simple solution for it. >> I would highly appreciate any feedback from the draft authors and/=20 >> or from the WG. >> >> Regards, >> Sasha >> >> > --Apple-Mail-7-505866687 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Nitin -


On Jan 10, = 2008, at 4:19 PM, David Ward wrote:


Nitin -

inline

On= Jan 10, 2008, at 4:10 PM, Nitin Bahadur wrote:

That=92s not sufficient from a = practical point of view. Here=92s = why.
=A0
=D8=A0=A0=A0=A0=A0=A0run BFD on bundled interfaces (any flavor) = centrally
Can=92t support very low = detection times. Only line cards can support tens of = ms.
=D8=A0=A0=A0=A0=A0=A0run BFD on all component links independently
This solution does not work for multi-hop = bfd=A0sessions. If the outgoing link for a = mhop=A0session is a link-bundle, then you would = need to create a 1=A0session per component link just to monitor = the health of a single bfd peer. Also, for a mhop=A0session, if there are link bundles on both = the peers, I=92m not sure how it would = work.

DW: The picture would be = that the component links in an L2 bundle are directly adjacent. =A0In an = L2 bundle situation where you want to test each link =A0independently = with bidir comms between two routers why would it be mhop? MHop session = are for those w/o being directly adjacent.




DW: Perhaps you meant that = two routers running a mhop BFD session that traversed a link bundle = somewhere inbetween. In this case there is nothing you can do as there = is nothing you can to to guarantee you are going to traverse the same = component links of the bundle inbetween two other routers. The = forwarding choice of how to balance those flows over the component links = is a local decision that the mhop BFD'ing routers cannot = bias.


I wasn't sure if you were = thinking of that case.


-DWard





=D8=A0=A0=A0=A0=A0=A0run BFD on a master component link
What if the master goes down? The link is = still UP. If you now assign the master to a different line card, you end = up with problem of=A0sequence number out of = sync.
=A0
I would be interested in knowing the = other variants that might help solve the above = issues.

DW: Many of them do not = require modifications to the protocol to be interoperable and would be = outside the scope of the BFD specification.

-DWard

=A0
Nitin
From:=A0David Ward [mailto:dward@cisco.com]=A0
Sent:=A0Thursday, January 10, 2008 = 1:51 PM
To:=A0Nitin Bahadur
Cc:=A0David Ward; Alexander = Vainshtein;=A0Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
=A0Re: = Resetting the=A0sequence number in an authenticated = BFD=A0session
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman'; ">=A0
Solutions include (and are alluded to in the = drafts):
run BFD on = bundled interfaces (any flavor) = centrally
run BFD on all component links = independently
run BFD on a master component = link
There are = other variants as well.
On Jan 10, = 2008, at 3:41 PM,=A0Nitin Bahadur=A0wrote:<= /div>
=A0=A0=A0 I agree that keeping = the=A0sequence number consistent between line = cards is not practical. We need a way for a system to indicate that it = wants to restart the=A0sequence.=A0
=A0Alexander Vainshtein [=A0
Sent:=A0Thursday, January 10, 2008 = 12:42 PM
To:=A0David Ward;=A0Dave = Katz
=A0Ronen = Sommer; BFD WG; Igor Danilovich
=A0Resetting the=A0sequence number in an authenticated = BFD=A0session
Importance:=A0HighHi = all,I have a = question related to the expected behavior of=A0sequence numbers in an aythenticated (MD5 = or SHA1) BFD=A0session.The = corresdponding=A0sections of = draft-ietf-bfd-base-06 state that, once the = packet has been authenticated by the receiver, its=A0sequence number MUST be checked; if its = value is out of range defined by the last received=A0sequence number and the Detect Multiplexor, = the packet MUST be discarded.This may = result in the a BFD=A0session going down in the situation when = the transceiver "loses" the information about = its last transmitted=A0sequence number. A = suitable=A0use=A0case=A0is a multilink = interface (LAG, ML-PPP, etc.) with the links residing in = different=A0line=A0cards, and e BFD implemented in one of = these=A0cards:=A0if this card=A0fails, = the BFD would=A0could be re-started in one of the remaining cards. Such = a restart would not affect the local=A0session = because=A0the BFD=A0machine = would=A0be restarted with=A0=A0=3D = 0, but keeping=A0=A0consistent between different = line cards=A0seems problematic. (Implemeting BFD in some = common card would resolve the situation with the multilink interfaces = but would raise=A0similar issues when the common = card fails).Note that = this problem would not occur=A0for a non-authenticated BFD=A0session.IMHO this = problem is real, and I do not=A0see a simple solution for = it.=A0I would = highly appreciate any feedback from the draft authors and/or from the = WG. In-Reply-To: <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchT17OkujRHVBY9REC/cjhfLDLFJgAAvAbg References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com> From: "Nitin Bahadur" To: "David Ward" X-OriginalArrivalTime: 10 Jan 2008 23:14:28.0316 (UTC) FILETIME=[8C6259C0:01C853DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Cc: Ronen Sommer , BFD WG , Igor Danilovich , Dave Katz Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C853DE.8BEF99E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The case I was thinking of was as follows.. =20 ____________ ________ | Bundle | | Bundle | =20 A +---------------------+ B ------ C ------ D +------------+ E =20 |____________ | =20 A and E are iBGP peers. iBGP doesn't know/care bout link bundling. The peers establish a BFD mhop session between them. The links A-B and D-E are link bundles. One cannot guarantee that the link bundle components will be on the same line-card. How can one maintain auth semantics if the line card on A hosting the BFD session goes down. =20 =20 ________________________________ =20 * run BFD on all component links independently This solution does not work for multi-hop bfd sessions. If the outgoing link for a mhop session is a link-bundle, then you would need to create a 1 session per component link just to monitor the health of a single bfd peer. Also, for a mhop session, if there are link bundles on both the peers, I'm not sure how it would work. =20 =20 DW: The picture would be that the component links in an L2 bundle are directly adjacent. In an L2 bundle situation where you want to test each link independently with bidir comms between two routers why would it be mhop? MHop session are for those w/o being directly adjacent. =20 =20 DW: Perhaps you meant that two routers running a mhop BFD session that traversed a link bundle somewhere inbetween. In this case there is nothing you can do as there is nothing you can to to guarantee you are going to traverse the same component links of the bundle inbetween two other routers. The forwarding choice of how to balance those flows over the component links is a local decision that the mhop BFD'ing routers cannot bias. =20 =20 ------_=_NextPart_001_01C853DE.8BEF99E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The case I was thinking of was as follows..

 

   = ;    ____________   =             &= nbsp;           &n= bsp; ________

   = ;   |    Bundle        = |  =             &= nbsp;           &n= bsp;|   Bundle |   

 A  = +---------------------+ B ------ C  ------ D +------------+ E =  

   = ;   |____________ |

 =

A and E are iBGP peers. iBGP = doesn’t know/care bout link bundling. The peers establish a BFD mhop = session between them. The links A-B and D-E = are link bundles. One cannot guarantee that the link bundle components will be on = the same line-card. How can one maintain auth semantics if the line card on = A hosting  the BFD session goes down.

 

 

 

Ø      run BFD on all component links = independently

This solution does not work for = multi-hop bfd sessions. If the outgoing = link for a mhop session is a link-bundle, = then you would need to create a 1 session per component link = just to monitor the health of a single bfd peer. Also, for a mhop session, if there are link = bundles on both the peers, I’m not sure how it would = work.

 

 

DW: The picture would be that the component links in an L2 = bundle are directly adjacent.  In an L2 bundle situation where you want to = test each link  independently with bidir comms between two routers why would = it be mhop? MHop session are for = those w/o being directly = adjacent.

 

 

DW: Perhaps you meant that two routers running a mhop BFD = session that traversed a link bundle somewhere inbetween. In this case there is nothing you can do as there is nothing you can to to guarantee = you are going to traverse the same = component links of the bundle inbetween two other routers. The forwarding choice = of how to balance those flows over = the component links is a local decision that the mhop BFD'ing routers cannot = bias.

 

 

------_=_NextPart_001_01C853DE.8BEF99E5-- From rtg-bfd-bounces@ietf.org Thu Jan 10 18:39:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6zx-00006f-1q; Thu, 10 Jan 2008 18:39:45 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD6zw-00006Y-5e for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 18:39:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6zv-00006O-H7 for rtg-bfd@ietf.org; Thu, 10 Jan 2008 18:39:43 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD6zu-0007yF-IA for rtg-bfd@ietf.org; Thu, 10 Jan 2008 18:39:43 -0500 X-IronPort-AV: E=Sophos;i="4.24,269,1196658000"; d="scan'208,217";a="82989615" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2008 18:39:42 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0ANdgcq029195; Thu, 10 Jan 2008 18:39:42 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0ANdbpi001033; Thu, 10 Jan 2008 23:39:37 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 18:39:37 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 18:39:37 -0500 In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E8B22FD@emailcorp3.jnpr.net> References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22FD@emailcorp3.jnpr.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: multipart/alternative; boundary=Apple-Mail-1-510350660 Message-Id: From: David Ward Date: Thu, 10 Jan 2008 17:39:26 -0600 To: "Nitin Bahadur" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 10 Jan 2008 23:39:37.0371 (UTC) FILETIME=[0FD9DEB0:01C853E2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16618; t=1200008382; x=1200872382; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20Resetting=20the=20sequence=20number=20i n=20an=20authenticated=20BFD=20session |Sender:=20 |To:=20=22Nitin=20Bahadur=22=20; bh=0cUgh+0vWC0TE/euPtKbrvEiWWPaIcsK6jiQw67rJlU=; b=mV7CbA/D65taK0e7HpQI8zZjst02i88CaFYJTE1nrFAP+SLGuOzGxEvXnH Wj4+mip9MSIKNRy0FbM8uheDDaBcq31d2anSeGCvtbfMEW0/lOFSaf6s0W+C K3lQJdOKPo; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 2.4 (++) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: Ronen Sommer , Dave Katz , Igor Danilovich , David Ward , BFD WG Subject: Re: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-1-510350660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed The solution for this is outside the scope of the spec. Note that =20 the problem you describe is not specific to auth at all, it is a =20 generic system problem. The problem is the same if you receive any =20 BFD notification over any link and you need to disseminate that =20 information to all component links. Discrim change, timer change, etc =20= they all fit into this category. You can home the BFD machine on one LC (yes, a form of =20 centralization) and fwd bfd packets to it, you can run BFD on all LCs =20= homing component links and send notifications between them =20 (proprietary solution) - there are many variants of this. It is much, =20= much harder to put the solution into forwarding chips themselves but, =20= again it is not an unsolvable problem either. In any event, the meta point is that this problem is not limited to =20 authentication seq_id rollover and unfort is not a solution that =20 requires specification for interoperability. Towards that end I know =20 of multiple interoperable implementations that work over bundles. -DWard On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote: > > The case I was thinking of was as follows.. > > ____________ ________ > | Bundle | | Bundle | > A +---------------------+ B ------ C ------ D +------------+ E > |____________ | > > A and E are iBGP peers. iBGP doesn=92t know/care bout link bundling. =20= > The peers establish a BFD mhop session between them. The links A-B =20 > and D-E are link bundles. One cannot guarantee that the link bundle =20= > components will be on the same line-card. How can one maintain auth =20= > semantics if the line card on A hosting the BFD session goes down. > > > > =D8 run BFD on all component links independently > This solution does not work for multi-hop bfd sessions. If the =20 > outgoing link for a mhop session is a link-bundle, then you would =20 > need to create a 1 session per component link just to monitor the =20 > health of a single bfd peer. Also, for a mhop session, if there are =20= > link bundles on both the peers, I=92m not sure how it would work. > > > DW: The picture would be that the component links in an L2 bundle =20 > are directly adjacent. In an L2 bundle situation where you want to =20= > test each link independently with bidir comms between two routers =20 > why would it be mhop? MHop session are for those w/o being directly =20= > adjacent. > > > DW: Perhaps you meant that two routers running a mhop BFD session =20 > that traversed a link bundle somewhere inbetween. In this case =20 > there is nothing you can do as there is nothing you can to to =20 > guarantee you are going to traverse the same component links of the =20= > bundle inbetween two other routers. The forwarding choice of how to =20= > balance those flows over the component links is a local decision =20 > that the mhop BFD'ing routers cannot bias. > > --Apple-Mail-1-510350660 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 The solution for this is outside the scope of the spec. =A0Note that the = problem you describe is not specific to auth at all, it is a generic = system problem. The problem is the same if you receive any BFD = notification over any link and you need to disseminate that information = to all component links. Discrim change, timer change, etc they all fit = into this category.

You can home the BFD = machine on one LC (yes, a form of centralization) and fwd bfd packets to = it, you can run BFD on all LCs homing component links and send = notifications between them (proprietary solution) - there are many = variants of this. It is much, much harder to put the solution into = forwarding chips themselves but, again it is not an unsolvable problem = either.

In = any event, the meta point is that this problem is not limited to = authentication seq_id rollover and unfort is not a solution that = requires specification for interoperability. Towards that end I know of = multiple interoperable implementations that work over = bundles.

-DWard=A0

On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote:

=A0
The = case=A0I was thinking of was as = follows..
=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 Bundle=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 Bundle |=A0=A0=A0
=A0A=A0 = +---------------------+ B ------ C=A0 ------ D +------------+ E = =A0
=A0=A0=A0=A0=A0 |____________ = |
=A0
A and E are = iBGP peers. iBGP doesn=92t know/care bout link bundling. The peers = establish a BFD mhop=A0session between them. The links A-B and D-E = are link bundles. One cannot guarantee that the link bundle components = will be on the same line-card. How can one maintain auth semantics if = the line card on A hosting =A0the BFD session goes = down.
=A0
=A0
=A0=A0=A0=A0=A0=A0run BFD on all component = links = independently
This solution = does not work for multi-hop bfd=A0sessions. If the outgoing link for a = mhop=A0session is a link-bundle, then you would = need to create a 1=A0session per component link just to monitor = the health of a single bfd peer. Also, for a mhop=A0session, if there are link bundles on both = the peers, I=92m not sure how it would = work.
DW: The = picture would be that the component links in an L2 bundle are directly = adjacent. =A0In an L2 bundle situation where you want to test each link = =A0independently with bidir comms between two routers why would it be = mhop? MHop=A0session are for those=A0w/o being directly = adjacent.
DW: Perhaps = you meant that two routers running a mhop BFD=A0session that traversed a link bundle somewhere inbetween. In = this case=A0there is nothing you can do as = there is nothing you can to to guarantee you are going to = traverse=A0the same component links of = the bundle inbetween two other routers. The forwarding choice of how to = balance those=A0flows over the component links = is a local decision that the mhop BFD'ing routers cannot = bias.
X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchT0v9dDEpg7rxcR+mJTDeR3cNbCwAZjNoE References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> From: Alexander Vainshtein To: "David Ward" , "Nitin Bahadur" X-OriginalArrivalTime: 11 Jan 2008 10:11:39.0598 (UTC) FILETIME=[5B427EE0:01C8543A] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: BFD WG , Ronen Sommer , Igor Danilovich , Dave Katz Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------_=_NextPart_001_01C8543A.5AD970FE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, Nitin and all, Please see inline below (blue italics)..Unfortunately it seems that none = of the options explicitly proposed by David resolve the issue. =20 Regards, Sasha ________________________________ From: David Ward [mailto:dward@cisco.com] Sent: Thu 1/10/2008 11:51 PM To: Nitin Bahadur Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; = Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD = session Solutions include (and are alluded to in the drafts):=20 run BFD on bundled interfaces (any flavor) centrally [Sasha] This rasies = the issue of the central component failover (as mentioned in my oriinal = message). =20 run BFD on all component links independently [Sasha] IMHO this is not a = viable option. E.g., consider a L3 1-hop situation where the bundled = interfaces run between one of the routers and a L2 switch, while the L3 = adjacency is unaware of bundling. This is easily achieved with LAG.=20 =20 run BFD on a master component link [Sasha] The failure of the LC that = carries the "master componet link" is the original scenario described in = my original email, and the issue remains unsloved IMO. There are other variants as well. -DWard On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: =09 Alexander, =20 I agree that keeping the sequence number consistent between line = cards is not practical. We need a way for a system to indicate that it = wants to restart the sequence. =20 Nitin =20 =09 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, January 10, 2008 12:42 PM To: David Ward; Dave Katz Cc: Ronen Sommer; BFD WG; Igor Danilovich Subject: Resetting the sequence number in an authenticated BFD session Importance: High =20 Hi all, I have a question related to the expected behavior of sequence numbers = in an aythenticated (MD5 or SHA1) BFD session. =20 The corresdponding sections of draft-ietf-bfd-base-06 state that, once = the packet has been authenticated by the receiver, its sequence number = MUST be checked; if its value is out of range defined by the last = received sequence number and the Detect Multiplexor, the packet MUST be = discarded. =20 This may result in the a BFD session going down in the situation when = the transceiver "loses" the information about its last transmitted = sequence number. A suitable use case is a multilink interface (LAG, = ML-PPP, etc.) with the links residing in different line cards, and e BFD = implemented in one of these cards: if this card fails, the BFD would = could be re-started in one of the remaining cards. Such a restart would = not affect the local session because the BFD machine would be restarted = with bfd.AuthSeqKnown =3D 0, but keeping bfd.XmitAuthSeq consistent = between different line cards seems problematic. (Implemeting BFD in some = common card would resolve the situation with the multilink interfaces = but would raise similar issues when the common card fails). =20 Note that this problem would not occur for a non-authenticated BFD = session. =20 IMHO this problem is real, and I do not see a simple solution for it.=20 I would highly appreciate any feedback from the draft authors and/or = from the WG. =20 Regards, Sasha =20 ------_=_NextPart_001_01C8543A.5AD970FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
David, Nitin = and all,
=0A=
Please see inline below = (blue italics)..Unfortunately it = seems that none of the options explicitly proposed by David resolve the = issue.
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;      Sasha
=0A=

=0A=
=0A= From: David Ward = [mailto:dward@cisco.com]
Sent: Thu 1/10/2008 11:51 = PM
To: Nitin Bahadur
Cc: David Ward; Alexander = Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
Subject: Re: Resetting the sequence number in an = authenticated BFD session

=0A=
Solutions include (and are alluded to in the drafts): =0A=

=0A=
run BFD on bundled interfaces (any flavor) centrally [Sasha] This rasies the issue of the central component = failover (as mentioned in my oriinal message).
=0A=
 
=0A=
run BFD on all component links independently [Sasha] IMHO this is not a viable option. E.g., consider = a L3 1-hop situation where the bundled interfaces run between one of the = routers and a L2 switch, while the L3 adjacency is unaware of bundling. = This is easily achieved with LAG.
=0A=
 
=0A=
run BFD on a master component link [Sasha] The failure of the LC that carries the "master = componet link" is the original scenario described in my original email, = and the issue remains unsloved IMO.
=0A=

=0A=
There are other variants as well.
=0A=

=0A=
-DWard
=0A=

=0A=
=0A=
On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote:

=0A=
=0A=
=0A=
Alexander,
=0A=
 
=0A=
   I agree that keeping the sequence number consistent = between line cards is not practical. We need a way for a system to = indicate that it wants to restart the sequence.
=0A=
 
=0A=
Nitin
=0A=
 
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
From: Alexander = Vainshtein [mailto:Alexander.Vainsht= ein@ecitele.com] 
Sent: Thursday, January 10, 2008 = 12:42 PM
To: David Ward; Dave Katz
Cc: Ronen Sommer; BFD WG; Igor = Danilovich
Subject: Resetting the sequence number in an = authenticated BFD session
Importance: High
=0A=
 
=0A=
=0A=
Hi = all,
=0A=
=0A=
I have a question related to the expected behavior = of sequence numbers in = an aythenticated (MD5 or SHA1) BFD session.
=0A=
=0A=
 
=0A=
=0A=
The corresdponding sections of = draft-ietf-bfd-base-06 state that, once the packet has been = authenticated by the receiver, its sequence number MUST be = checked; if its value is out of range defined by the last received sequence number and the = Detect Multiplexor, the packet MUST be = discarded.
=0A=
=0A=
 
=0A=
=0A=
This may result in the a BFD session going down in the = situation when the transceiver "loses" the information about its last = transmitted sequence = number. A suitable use case is a multilink = interface (LAG, ML-PPP, etc.) with the links residing in = different line cards, and e BFD implemented in one of = these cards: if = this card fails, the BFD would could be re-started in one of = the remaining cards. Such a restart would not affect the = local session because the BFD machine would be = restarted with bfd.AuthSeqKnown =3D = 0, but keeping bfd.XmitAuthSeq consistent between different = line cards seems = problematic. (Implemeting BFD in some common card would resolve the = situation with the multilink interfaces but would raise similar issues when the = common card fails).
=0A=
=0A=
 
=0A=
=0A=
Note that this problem would not occur for a = non-authenticated BFD session.
=0A=
=0A=
 
=0A=
=0A=
IMHO this problem is real, and I do not see a simple solution for = it. 
=0A=
=0A=
I would highly appreciate any feedback from the = draft authors and/or from the WG.
=0A=
=0A=
 
=0A=
=0A=
Regards,
=0A=
=0A=
           =        Sasha
=0A=
=0A=
 

------_=_NextPart_001_01C8543A.5AD970FE-- From rtg-bfd-bounces@ietf.org Fri Jan 11 05:22:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDH1Z-00081i-63; Fri, 11 Jan 2008 05:22:05 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDH1Y-00081T-07 for rtg-bfd-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 05:22:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDH1X-00081K-M9 for rtg-bfd@ietf.org; Fri, 11 Jan 2008 05:22:03 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDH1Q-0002Ct-3n for rtg-bfd@ietf.org; Fri, 11 Jan 2008 05:22:03 -0500 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 11 Jan 2008 12:39:38 +0200 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jan 2008 12:21:55 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Fri, 11 Jan 2008 12:21:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8543B.C9AA2348" Date: Fri, 11 Jan 2008 12:21:54 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD0252D70C@ILPTEX02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchT4hx67GfswS3rQBuoMG1/M2U9KQAWGAHY References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22FD@emailcorp3.jnpr.net> From: Alexander Vainshtein To: "David Ward" , "Nitin Bahadur" X-OriginalArrivalTime: 11 Jan 2008 10:21:55.0126 (UTC) FILETIME=[CA249D60:01C8543B] X-Spam-Score: 1.8 (+) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Cc: BFD WG , Ronen Sommer , Igor Danilovich , Dave Katz Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------_=_NextPart_001_01C8543B.C9AA2348 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, Nitin and all, =20 IMHO the problem raised is specific because it represents a combination = of situations: 1.=09 Handling of a non-planned event is required *=09 From my experience, card failures fail quite often into this category=20 *=09 Since the ecent is non-planned, the BFD machine cannot prepare the = peer for this event. Handling of planned events could, e.g., begin with = the peer expecting such an event decalring the BFD session = administratively down and thus precluding any undesirable action by the = peer 2.=09 The event affects the authentication procedure. This means (and my = reading of the draft) that regardless of what the BFD machine after the = event tries to do, it will not be achieved because the packets it sends = shall not be authenticated and hence shall not affect the peer behavior. The real-time side of the story (namely sequence numbers chagning quite = fast) makes any solution based on synchronization between tow = incarnations (before and after the event) of the BFD machine very = difficult. Regards, Sasha ________________________________ From: David Ward [mailto:dward@cisco.com] Sent: Fri 1/11/2008 1:39 AM To: Nitin Bahadur Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; = Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD = session The solution for this is outside the scope of the spec. Note that the = problem you describe is not specific to auth at all, it is a generic = system problem. The problem is the same if you receive any BFD = notification over any link and you need to disseminate that information = to all component links. Discrim change, timer change, etc they all fit = into this category.=20 You can home the BFD machine on one LC (yes, a form of centralization) = and fwd bfd packets to it, you can run BFD on all LCs homing component = links and send notifications between them (proprietary solution) - there = are many variants of this. It is much, much harder to put the solution = into forwarding chips themselves but, again it is not an unsolvable = problem either. In any event, the meta point is that this problem is not limited to = authentication seq_id rollover and unfort is not a solution that = requires specification for interoperability. Towards that end I know of = multiple interoperable implementations that work over bundles. -DWard=20 On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote: =09 =20 The case I was thinking of was as follows.. =20 ____________ ________ | Bundle | | Bundle | =20 A +---------------------+ B ------ C ------ D +------------+ E =20 |____________ | =20 A and E are iBGP peers. iBGP doesn't know/care bout link bundling. The = peers establish a BFD mhop session between them. The links A-B and D-E = are link bundles. One cannot guarantee that the link bundle components = will be on the same line-card. How can one maintain auth semantics if = the line card on A hosting the BFD session goes down. =20 =20 =09 ________________________________ =20 * run BFD on all component links independently This solution does not work for multi-hop bfd sessions. If the outgoing = link for a mhop session is a link-bundle, then you would need to create = a 1 session per component link just to monitor the health of a single = bfd peer. Also, for a mhop session, if there are link bundles on both = the peers, I'm not sure how it would work. =20 =20 DW: The picture would be that the component links in an L2 bundle are = directly adjacent. In an L2 bundle situation where you want to test = each link independently with bidir comms between two routers why would = it be mhop? MHop session are for those w/o being directly adjacent. =20 =20 DW: Perhaps you meant that two routers running a mhop BFD session that = traversed a link bundle somewhere inbetween. In this case there is = nothing you can do as there is nothing you can to to guarantee you are = going to traverse the same component links of the bundle inbetween two = other routers. The forwarding choice of how to balance those flows over = the component links is a local decision that the mhop BFD'ing routers = cannot bias. =20 =20 ------_=_NextPart_001_01C8543B.C9AA2348 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
David, Nitin = and all,
=0A=
 
=0A=
IMHO the problem raised is specific because it represents = a combination of situations:
=0A=
    =0A=
  1. =0A=
    Handling of a non-planned event is required
    2. =0A=
      =0A=
    • =0A=
      From my experience, card failures fail quite often into this = category
      • =0A=
    • =0A=
      Since the ecent is non-planned, the BFD machine cannot prepare the = peer for this event. Handling of planned events could, e.g., begin with = the peer expecting such an event decalring the BFD session = administratively down and thus precluding any undesirable action by the = peer
    =0A=
  2. =0A=
    The event affects the authentication procedure. This means (and my = reading of the draft) that regardless of what the BFD machine after the = event tries to do, it will not be achieved because the packets it sends = shall not be authenticated and hence shall not affect the peer = behavior.
=0A=

The real-time side of the story (namely sequence numbers chagning = quite fast) makes any solution based on synchronization between tow = incarnations (before and after the event) of the BFD machine very = difficult.

=0A=

Regards,

=0A=

           &nbs= p;     Sasha

=0A=
=0A=
=0A=
=0A=
From: David Ward = [mailto:dward@cisco.com]
Sent: Fri 1/11/2008 1:39 = AM
To: Nitin Bahadur
Cc: David Ward; Alexander = Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
Subject: Re: Resetting the sequence number in an = authenticated BFD session

=0A=
The solution for this is outside the scope of the spec.  Note = that the problem you describe is not specific to auth at all, it is a = generic system problem. The problem is the same if you receive any BFD = notification over any link and you need to disseminate that information = to all component links. Discrim change, timer change, etc they all fit = into this category. =0A=

=0A=
You can home the BFD machine on one LC (yes, a form of = centralization) and fwd bfd packets to it, you can run BFD on all LCs = homing component links and send notifications between them (proprietary = solution) - there are many variants of this. It is much, much harder to = put the solution into forwarding chips themselves but, again it is not = an unsolvable problem either.
=0A=

=0A=
In any event, the meta point is that this problem is not limited to = authentication seq_id rollover and unfort is not a solution that = requires specification for interoperability. Towards that end I know of = multiple interoperable implementations that work over bundles.
=0A=
=0A=

=0A=
-DWard 
=0A=

=0A=
=0A=
On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote:

=0A=
=0A=
=0A=
 
=0A=
The case I was thinking of was as = follows..
=0A=
 
=0A=
       ____________   =             &= nbsp;           &n= bsp; ________
=0A=
      |    = Bundle        |  =             &= nbsp;           &n= bsp;|   Bundle |   
=0A=
 A  = +---------------------+ B ------ C  ------ D +------------+ E =  
=0A=
      |____________ |
=0A=
 
=0A=
A and E are = iBGP peers. iBGP doesn’t know/care bout link bundling. The peers = establish a BFD mhop session between them. The = links A-B and D-E are link bundles. One cannot guarantee that the link = bundle components will be on the same line-card. How can one maintain = auth semantics if the line card on A hosting  the BFD session goes = down.
=0A=
 
=0A=
 
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
 
=0A=
=0A=
=D8      run BFD on all component = links independently
=0A=
=0A=
This solution does not work for = multi-hop bfd sessions. = If the outgoing link for a mhop session is a link-bundle, = then you would need to create a 1 session per component link = just to monitor the health of a single bfd peer. Also, for a mhop session, if there are link = bundles on both the peers, I’m not sure how it would = work.
=0A=
=0A=
 
=0A=
=0A=
 
=0A=
=0A=
DW: The picture would be that the component = links in an L2 bundle are directly adjacent.  In an L2 bundle = situation where you want to test each link  independently with = bidir comms between two routers why would it be mhop? MHop session are for those w/o being directly = adjacent.
=0A=
=0A=
 
=0A=
=0A=
 
=0A=
=0A=
DW: Perhaps you meant that two routers running = a mhop BFD session that = traversed a link bundle somewhere inbetween. In this case there is nothing you can do = as there is nothing you can to to guarantee you are going to = traverse the same = component links of the bundle inbetween two other routers. The = forwarding choice of how to balance those flows over the component = links is a local decision that the mhop BFD'ing routers cannot = bias.
=0A=
=0A=
 
=0A=
 

------_=_NextPart_001_01C8543B.C9AA2348-- From rtg-bfd-bounces@ietf.org Fri Jan 11 09:19:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKj4-0003F1-5P; Fri, 11 Jan 2008 09:19:14 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDKj2-0003Cd-Qi for rtg-bfd-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 09:19:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKj2-0003CV-Gs for rtg-bfd@ietf.org; Fri, 11 Jan 2008 09:19:12 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDKj1-0005lw-6Z for rtg-bfd@ietf.org; Fri, 11 Jan 2008 09:19:12 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2008 09:19:10 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0BEJAPW017199; Fri, 11 Jan 2008 09:19:10 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0BEJ073012452; Fri, 11 Jan 2008 14:19:10 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:19:01 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:19:01 -0500 In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252D70B@ILPTEX02.ecitele.com> References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <64122293A6365B4A9794DC5636F9ACFD0252D70B@ILPTEX02.ecitele.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: multipart/alternative; boundary=Apple-Mail-9-563115903 Message-Id: From: David Ward Date: Fri, 11 Jan 2008 08:18:51 -0600 To: Alexander Vainshtein X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Jan 2008 14:19:01.0317 (UTC) FILETIME=[E99D1750:01C8545C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17548; t=1200061150; x=1200925150; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20Resetting=20the=20sequence=20number=20i n=20an=20authenticated=20BFD=20session |Sender:=20 |To:=20Alexander=20Vainshtein=20; bh=VmXCkb25O0QXKAleNZQP9gNgKPeKZPiT51SAnXx9z+0=; b=E/7tDb6WnONwjrd3cuoezlbYkfB2B77Asx//kkSJxYYUmOSHVb5rYSgPri dk8MV2CS1UIcKoT3PylcGLPjzP/GrgXzdqgW3aCbCmv9s4bWNz9k9dF5V6iJ PVayMSqURM; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: Ronen Sommer , Dave Katz , Igor Danilovich , David Ward , BFD WG Subject: Re: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-9-563115903 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Sasha - I think I already covered your points on centralization and master component link. WRT the issue that a L3 device is connected to an L2 device via a bundled interface and the far L3 device is single attached ... BFD is currently an L3 solution. You'd have to run LACP, UDLR or BFD at L3 to the L2 device to cover this scenario. -DWard On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote: > David, Nitin and all, > Please see inline below (blue italics)..Unfortunately it seems that > none of the options explicitly proposed by David resolve the issue. > > Regards, > Sasha > > From: David Ward [mailto:dward@cisco.com] > Sent: Thu 1/10/2008 11:51 PM > To: Nitin Bahadur > Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD > WG; Igor Danilovich > Subject: Re: Resetting the sequence number in an authenticated BFD > session > > Solutions include (and are alluded to in the drafts): > > run BFD on bundled interfaces (any flavor) centrally [Sasha] This > rasies the issue of the central component failover (as mentioned in > my oriinal message). > > run BFD on all component links independently [Sasha] IMHO this is > not a viable option. E.g., consider a L3 1-hop situation where the > bundled interfaces run between one of the routers and a L2 switch, > while the L3 adjacency is unaware of bundling. This is easily > achieved with LAG. > > run BFD on a master component link [Sasha] The failure of the LC > that carries the "master componet link" is the original scenario > described in my original email, and the issue remains unsloved IMO. > > There are other variants as well. > > -DWard > > On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: > >> Alexander, >> >> I agree that keeping the sequence number consistent between >> line cards is not practical. We need a way for a system to >> indicate that it wants to restart the sequence. >> >> Nitin >> >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Thursday, January 10, 2008 12:42 PM >> To: David Ward; Dave Katz >> Cc: Ronen Sommer; BFD WG; Igor Danilovich >> Subject: Resetting the sequence number in an authenticated BFD >> session >> Importance: High >> >> Hi all, >> I have a question related to the expected behavior of sequence >> numbers in an aythenticated (MD5 or SHA1) BFD session. >> >> The corresdponding sections of draft-ietf-bfd-base-06 state that, >> once the packet has been authenticated by the receiver, its >> sequence number MUST be checked; if its value is out of range >> defined by the last received sequence number and the Detect >> Multiplexor, the packet MUST be discarded. >> >> This may result in the a BFD session going down in the situation >> when the transceiver "loses" the information about its last >> transmitted sequence number. A suitable use case is a multilink >> interface (LAG, ML-PPP, etc.) with the links residing in different >> line cards, and e BFD implemented in one of these cards: if this >> card fails, the BFD would could be re-started in one of the >> remaining cards. Such a restart would not affect the local session >> because the BFD machine would be restarted with bfd.AuthSeqKnown = >> 0, but keeping bfd.XmitAuthSeq consistent between different line >> cards seems problematic. (Implemeting BFD in some common card >> would resolve the situation with the multilink interfaces but >> would raise similar issues when the common card fails). >> >> Note that this problem would not occur for a non-authenticated BFD >> session. >> >> IMHO this problem is real, and I do not see a simple solution for it. >> I would highly appreciate any feedback from the draft authors and/ >> or from the WG. >> >> Regards, >> Sasha >> > --Apple-Mail-9-563115903 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Sasha -


I think I already covered = your points on centralization and master component link. WRT the issue = that a L3 device is connected to an L2 device via a bundled interface = and the far L3 device is single attached ... BFD is currently an L3 = solution. You'd have to run LACP, UDLR or BFD at L3 to the L2 device to = cover this scenario.

-DWard


On Jan 11, = 2008, at 4:11 AM, Alexander Vainshtein wrote:

David, Nitin and = all,
Please = see inline below (blue = italics)..Unfortunately it seems that none of the options = explicitly proposed by David resolve the issue.
=A0
Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Sasha

From: David = Ward [mailto:dward@cisco.com]
Sent: Thu 1/10/2008 11:51 PM
To: Nitin Bahadur
Cc: David = Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
Subject: Re: Resetting the sequence number in an = authenticated BFD session

Solutions include = (and are alluded to in the drafts):

run BFD on bundled = interfaces (any flavor) centrally [Sasha] = This rasies the issue of the central component failover (as mentioned in = my oriinal message).
=A0
run BFD on = all component links independently [Sasha] = IMHO this is not a viable option. E.g., consider a L3 1-hop situation = where the bundled interfaces run between one of the routers and a L2 = switch, while the L3 adjacency is unaware of bundling. This is easily = achieved with LAG.
=A0
run BFD on a master = component link [Sasha] The failure of the LC = that carries the "master componet link" is the original scenario = described in my original email, and the issue remains unsloved = IMO.

=
There are other variants as well.

-DWard

=
On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote:

Alexander,
=A0
=A0=A0 I = agree that keeping the=A0sequence number consistent = between line cards is not practical. We need a way for a system to = indicate that it wants to restart the=A0sequence.
=
=A0
Nitin
=A0
=
=A0
Hi = all,
I have a = question related to the expected behavior of=A0sequence numbers in an = aythenticated (MD5 or SHA1) BFD=A0session.
=A0
=
The corresdponding=A0sections of = draft-ietf-bfd-base-06 state that, once the packet has been = authenticated by the receiver, its=A0sequence number MUST be = checked; if its value is out of range defined by the last received=A0sequence number and the Detect = Multiplexor, the packet MUST be discarded.
=
=A0
This may result in the a BFD=A0session going down in the = situation when the transceiver "loses" the information about its last = transmitted=A0sequence = number. A suitable=A0use=A0case=A0is a multilink = interface (LAG, ML-PPP, etc.) with the links residing in = different=A0line=A0cards, and e BFD implemented in one of these=A0cards:=A0if this card=A0fails, = the BFD would=A0could be re-started in one of the remaining cards. Such = a restart would not affect the local=A0session because=A0the BFD=A0machine= would=A0be restarted with=A0bfd.AuthSeqKnown=A0=3D = 0, but keeping=A0bfd.XmitAuthSeq=A0consistent between different = line cards=A0seems = problematic. (Implemeting BFD in some common card would resolve the = situation with the multilink interfaces but would raise=A0similar issues when the common = card fails).
=A0
Note that = this problem would not occur=A0for a non-authenticated BFD=A0session.
=A0
=
IMHO this problem is real, = and I do not=A0see a simple = solution for it.=A0
I would highly appreciate any feedback from the = draft authors and/or from the WG.
=A0
Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Sasha
=A0
<= br>

= --Apple-Mail-9-563115903-- From rtg-bfd-bounces@ietf.org Fri Jan 11 09:23:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKnG-0002yR-1n; Fri, 11 Jan 2008 09:23:34 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDKnE-0002xO-DZ for rtg-bfd-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 09:23:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKnE-0002xG-0V for rtg-bfd@ietf.org; Fri, 11 Jan 2008 09:23:32 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDKnC-0008Of-Od for rtg-bfd@ietf.org; Fri, 11 Jan 2008 09:23:31 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2008 09:23:30 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0BENUK1020068; Fri, 11 Jan 2008 09:23:30 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0BENUpi020860; Fri, 11 Jan 2008 14:23:30 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:23:30 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:23:29 -0500 In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252D70C@ILPTEX02.ecitele.com> References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22FD@emailcorp3.jnpr.net> <64122293A6365B4A9794DC5636F9ACFD0252D70C@ILPTEX02.ecitele.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: multipart/alternative; boundary=Apple-Mail-10-563384303 Message-Id: <391301D2-1265-41AA-ABC7-7FFCFD1188E5@cisco.com> From: David Ward Date: Fri, 11 Jan 2008 08:23:19 -0600 To: Alexander Vainshtein X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Jan 2008 14:23:29.0708 (UTC) FILETIME=[89964EC0:01C8545D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19153; t=1200061410; x=1200925410; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20Resetting=20the=20sequence=20number=20i n=20an=20authenticated=20BFD=20session |Sender:=20 |To:=20Alexander=20Vainshtein=20; bh=uIZKz7hoIR/1ZeU1jgRTU8cCI3T0Bt5EQhyOyy46RU0=; b=fQXk3NmFpfuvyW9AieiMmxfZIXSz/IX4QuzKIN5Ihyya7KbJADQnXYr7lw gfC3BSZhaq7jGQvnOUQec/+j5rt2pxrcUueHaT1QRvqr2hH17pGHUOhVRRIT 57qQcZVFFE; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: Ronen Sommer , Dave Katz , Igor Danilovich , David Ward , BFD WG Subject: Re: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-10-563384303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Sasha - On Jan 11, 2008, at 4:21 AM, Alexander Vainshtein wrote: > David, Nitin and all, > > IMHO the problem raised is specific because it represents a =20 > combination of situations: > Handling of a non-planned event is required > =46rom my experience, card failures fail quite often into this = category This is a generic problem. > > Since the ecent is non-planned, the BFD machine cannot prepare the =20 > peer for this event. Handling of planned events could, e.g., begin =20 > with the peer expecting > such an event decalring the BFD session administratively down and =20 > thus precluding any undesirable action by the peer This is also a generic problem. > The event affects the authentication procedure. This means (and my =20 > reading of the draft) that regardless of what the BFD machine after =20= > the event tries to do, it will not be achieved because the packets =20 > it sends shall not be authenticated and hence shall not affect the =20 > peer behavior. Again, this is no different if other "helping" BFD processes didn't =20 have any of the session state. Any BFD information given w/ unknown =20 session information is ignored. This isn't limited to Auth. > The real-time side of the story (namely sequence numbers chagning =20 > quite fast) makes any solution based on synchronization between tow =20= > incarnations (before and after the event) of the BFD machine very =20 > difficult. > > > Difficult but, not impossible. Again, there are multiple =20 interoperable implementations that work over enet bundles, MLPP, etc. =20= Fortunately none of them change the packets on the wire or protocol =20 state machine. -DWard > Regards, > > Sasha > > From: David Ward [mailto:dward@cisco.com] > Sent: Fri 1/11/2008 1:39 AM > To: Nitin Bahadur > Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD =20 > WG; Igor Danilovich > Subject: Re: Resetting the sequence number in an authenticated BFD =20 > session > > The solution for this is outside the scope of the spec. Note that =20 > the problem you describe is not specific to auth at all, it is a =20 > generic system problem. The problem is the same if you receive any =20 > BFD notification over any link and you need to disseminate that =20 > information to all component links. Discrim change, timer change, =20 > etc they all fit into this category. > > You can home the BFD machine on one LC (yes, a form of =20 > centralization) and fwd bfd packets to it, you can run BFD on all =20 > LCs homing component links and send notifications between them =20 > (proprietary solution) - there are many variants of this. It is =20 > much, much harder to put the solution into forwarding chips =20 > themselves but, again it is not an unsolvable problem either. > > In any event, the meta point is that this problem is not limited to =20= > authentication seq_id rollover and unfort is not a solution that =20 > requires specification for interoperability. Towards that end I =20 > know of multiple interoperable implementations that work over bundles. > > -DWard > > On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote: > >> >> The case I was thinking of was as follows.. >> >> ____________ ________ >> | Bundle | | Bundle | >> A +---------------------+ B ------ C ------ D +------------+ E >> |____________ | >> >> A and E are iBGP peers. iBGP doesn=92t know/care bout link bundling. =20= >> The peers establish a BFD mhop session between them. The links A-B =20= >> and D-E are link bundles. One cannot guarantee that the link =20 >> bundle components will be on the same line-card. How can one =20 >> maintain auth semantics if the line card on A hosting the BFD =20 >> session goes down. >> >> >> >> =D8 run BFD on all component links independently >> This solution does not work for multi-hop bfd sessions. If the =20 >> outgoing link for a mhop session is a link-bundle, then you would =20 >> need to create a 1 session per component link just to monitor the =20 >> health of a single bfd peer. Also, for a mhop session, if there =20 >> are link bundles on both the peers, I=92m not sure how it would work. >> >> >> DW: The picture would be that the component links in an L2 bundle =20 >> are directly adjacent. In an L2 bundle situation where you want =20 >> to test each link independently with bidir comms between two =20 >> routers why would it be mhop? MHop session are for those w/o being =20= >> directly adjacent. >> >> >> DW: Perhaps you meant that two routers running a mhop BFD session =20 >> that traversed a link bundle somewhere inbetween. In this case =20 >> there is nothing you can do as there is nothing you can to to =20 >> guarantee you are going to traverse the same component links of =20 >> the bundle inbetween two other routers. The forwarding choice of =20 >> how to balance those flows over the component links is a local =20 >> decision that the mhop BFD'ing routers cannot bias. >> >> > --Apple-Mail-10-563384303 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Sasha -


On Jan 11, = 2008, at 4:21 AM, Alexander Vainshtein wrote:

David, Nitin and = all,
=A0
IMHO the problem = raised is specific because it represents a combination of = situations:
  1. Handling of a non-planned = event is required
    • =46rom my experience, card = failures fail quite often into this = category

This is a generic = problem.

    • Since the ecent is = non-planned, the BFD machine cannot prepare the peer for this event. = Handling of planned events could, e.g., begin with the peer = expecting
    • such an event decalring the BFD = session administratively down and thus precluding any undesirable action = by the peer

This is = also a generic problem.

  1. The event affects the authentication procedure. = This means (and my reading of the draft) that regardless of what the BFD = machine after the event tries to do, it will not be achieved because the = packets it sends shall not be authenticated and hence shall not affect = the peer behavior.

Again, this is no = different if other "helping" BFD processes didn't have any of the = session state. Any BFD information given w/ unknown session information = is ignored. This isn't limited to Auth.

The real-time side of the story (namely sequence = numbers chagning quite fast) makes any solution based on synchronization = between tow incarnations (before and after the event) of the BFD machine = very difficult.



Difficult but, not = impossible. Again, there are multiple interoperable implementations that = work over enet bundles, MLPP, etc. Fortunately none of them change the = packets on the wire or protocol state machine.

-DWard



Regards,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Sasha

From: David Ward [mailto:dward@cisco.com]
Sent: Fri 1/11/2008 1:39 AM
To: Nitin Bahadur
Cc: David = Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
Subject: Re: Resetting the sequence number in an = authenticated BFD session

The solution for = this is outside the scope of the spec. =A0Note that the problem you = describe is not specific to auth at all, it is a generic system problem. = The problem is the same if you receive any BFD notification over any = link and you need to disseminate that information to all component = links. Discrim change, timer change, etc they all fit into this = category.

You = can home the BFD machine on one LC (yes, a form of centralization) and = fwd bfd packets to it, you can run BFD on all LCs homing component links = and send notifications between them (proprietary solution) - there are = many variants of this. It is much, much harder to put the solution into = forwarding chips themselves but, again it is not an unsolvable problem = either.

In = any event, the meta point is that this problem is not limited to = authentication seq_id rollover and unfort is not a solution that = requires specification for interoperability. Towards that end I know of = multiple interoperable implementations that work over bundles.
=

-DWard=A0
=

On Jan 10, 2008, at 5:14 PM, Nitin Bahadur = wrote:

=A0
The case=A0I was thinking of was as = follows..
=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 = Bundle=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 Bundle |=A0=A0=A0
=A0A=A0 +---------------------+ B ------ C=A0 ------ D = +------------+ E =A0
=A0=A0=A0=A0=A0 |____________ = |
=A0
A and E are iBGP peers. iBGP doesn=92t = know/care bout link bundling. The peers establish a BFD mhop=A0session between them. The = links A-B and D-E are link bundles. One cannot guarantee that the link = bundle components will be on the same line-card. How can one maintain = auth semantics if the line card on A hosting =A0the BFD session goes = down.
=A0
=A0
=
=A0
=D8=A0=A0=A0=A0=A0=A0run BFD on all component = links independently
This solution does not work for = multi-hop bfd=A0sessions. = If the outgoing link for a mhop=A0session is a link-bundle, then = you would need to create a 1=A0session per component link = just to monitor the health of a single bfd peer. Also, for a mhop=A0session, if there are link = bundles on both the peers, I=92m not sure how it would = work.
=A0
=A0
DW: The picture would be that the component = links in an L2 bundle are directly adjacent. =A0In an L2 bundle = situation where you want to test each link =A0independently with bidir = comms between two routers why would it be mhop? MHop=A0session are for those=A0w/o being directly = adjacent.
=A0
=A0
DW: Perhaps you = meant that two routers running a mhop BFD=A0session that traversed a link = bundle somewhere inbetween. In this case=A0there is nothing you can do as = there is nothing you can to to guarantee you are going to traverse=A0the same component links of = the bundle inbetween two other routers. The forwarding choice of how to = balance those=A0flows over = the component links is a local decision that the mhop BFD'ing routers = cannot bias.
=A0
=A0
<= br>

= --Apple-Mail-10-563384303-- From rtg-bfd-bounces@ietf.org Fri Jan 11 13:07:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDOI7-0003pb-7w; Fri, 11 Jan 2008 13:07:39 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDOI6-0003pW-1K for rtg-bfd-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 13:07:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDOI5-0003pO-KK for rtg-bfd@ietf.org; Fri, 11 Jan 2008 13:07:37 -0500 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDOI4-0007LJ-Tr for rtg-bfd@ietf.org; Fri, 11 Jan 2008 13:07:37 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5197E9FD90D; Fri, 11 Jan 2008 10:07:36 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14737-02; Fri, 11 Jan 2008 10:07:36 -0800 (PST) Received: from PARBETM2XP2 (unknown [172.31.253.219]) by prattle.redback.com (Postfix) with ESMTP id 6922A9FD90C; Fri, 11 Jan 2008 10:07:35 -0800 (PST) From: "Peter Arberg" To: "'David Ward'" , "'Alexander Vainshtein'" Date: Fri, 11 Jan 2008 10:07:30 -0800 Organization: Redback Networks Inc. Message-ID: <032d01c8547c$d59e2c10$0a01a8c0@ad.redback.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032E_01C85439.C77AEC10" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchUXZNMauHh/oRTSyOKOfFhwu/mmwAHu8FQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <391301D2-1265-41AA-ABC7-7FFCFD1188E5@cisco.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 570a5b81f8c75fea8dcc4c9f6a8a6e54 Cc: 'BFD WG' , 'Ronen Sommer' , 'Igor Danilovich' , 'Dave Katz' Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_032E_01C85439.C77AEC10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi David, When you say: --- Difficult but, not impossible. Again, there are multiple interoperable implementations that work over enet bundles, MLPP, etc. Fortunately none of them change the packets on the wire or protocol state machine. --- I take it you are refering to BFD over a link-bundle, where the bundle is considered "1" link, so just 1 BFD session, so it is a bundle "keepalive" instead of a per link inside the bundle monitoring/keepalive. correct ? thanks, Peter _____ From: David Ward [mailto:dward@cisco.com] Sent: 11. januar 2008 06:23 To: Alexander Vainshtein Cc: Ronen Sommer; Dave Katz; Igor Danilovich; David Ward; BFD WG Subject: Re: Resetting the sequence number in an authenticated BFD session Sasha - On Jan 11, 2008, at 4:21 AM, Alexander Vainshtein wrote: David, Nitin and all, IMHO the problem raised is specific because it represents a combination of situations: 1. Handling of a non-planned event is required * From my experience, card failures fail quite often into this category This is a generic problem. * * Since the ecent is non-planned, the BFD machine cannot prepare the peer for this event. Handling of planned events could, e.g., begin with the peer expecting * such an event decalring the BFD session administratively down and thus precluding any undesirable action by the peer This is also a generic problem. 2. The event affects the authentication procedure. This means (and my reading of the draft) that regardless of what the BFD machine after the event tries to do, it will not be achieved because the packets it sends shall not be authenticated and hence shall not affect the peer behavior. Again, this is no different if other "helping" BFD processes didn't have any of the session state. Any BFD information given w/ unknown session information is ignored. This isn't limited to Auth. The real-time side of the story (namely sequence numbers chagning quite fast) makes any solution based on synchronization between tow incarnations (before and after the event) of the BFD machine very difficult. Difficult but, not impossible. Again, there are multiple interoperable implementations that work over enet bundles, MLPP, etc. Fortunately none of them change the packets on the wire or protocol state machine. -DWard Regards, Sasha _____ From: David Ward [mailto:dward@cisco.com] Sent: Fri 1/11/2008 1:39 AM To: Nitin Bahadur Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD session The solution for this is outside the scope of the spec. Note that the problem you describe is not specific to auth at all, it is a generic system problem. The problem is the same if you receive any BFD notification over any link and you need to disseminate that information to all component links. Discrim change, timer change, etc they all fit into this category. You can home the BFD machine on one LC (yes, a form of centralization) and fwd bfd packets to it, you can run BFD on all LCs homing component links and send notifications between them (proprietary solution) - there are many variants of this. It is much, much harder to put the solution into forwarding chips themselves but, again it is not an unsolvable problem either. In any event, the meta point is that this problem is not limited to authentication seq_id rollover and unfort is not a solution that requires specification for interoperability. Towards that end I know of multiple interoperable implementations that work over bundles. -DWard On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote: The case I was thinking of was as follows.. ____________ ________ | Bundle | | Bundle | A +---------------------+ B ------ C ------ D +------------+ E |____________ | A and E are iBGP peers. iBGP doesn't know/care bout link bundling. The peers establish a BFD mhop session between them. The links A-B and D-E are link bundles. One cannot guarantee that the link bundle components will be on the same line-card. How can one maintain auth semantics if the line card on A hosting the BFD session goes down. _____ * run BFD on all component links independently This solution does not work for multi-hop bfd sessions. If the outgoing link for a mhop session is a link-bundle, then you would need to create a 1 session per component link just to monitor the health of a single bfd peer. Also, for a mhop session, if there are link bundles on both the peers, I'm not sure how it would work. DW: The picture would be that the component links in an L2 bundle are directly adjacent. In an L2 bundle situation where you want to test each link independently with bidir comms between two routers why would it be mhop? MHop session are for those w/o being directly adjacent. DW: Perhaps you meant that two routers running a mhop BFD session that traversed a link bundle somewhere inbetween. In this case there is nothing you can do as there is nothing you can to to guarantee you are going to traverse the same component links of the bundle inbetween two other routers. The forwarding choice of how to balance those flows over the component links is a local decision that the mhop BFD'ing routers cannot bias. ------=_NextPart_000_032E_01C85439.C77AEC10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi David,
 
When you say:
 
---
Difficult but, not impossible. Again, there are = multiple=20 interoperable implementations that work over enet bundles, MLPP, etc.=20 Fortunately none of them change the packets on the wire or protocol = state=20 machine.
---
 
I take it you are refering to BFD over a link-bundle, where the = bundle is=20 considered "1" link, so
just 1 BFD session, so it is a bundle "keepalive" instead of a = per link=20 inside the bundle
monitoring/keepalive.
 
correct ?
 
thanks,
Peter
 
 

From: David Ward = [mailto:dward@cisco.com]=20
Sent: 11. januar 2008 06:23
To: Alexander=20 Vainshtein
Cc: Ronen Sommer; Dave Katz; Igor Danilovich; = David Ward;=20 BFD WG
Subject: Re: Resetting the sequence number in an=20 authenticated BFD session

Sasha -


On Jan 11, 2008, at 4:21 AM, Alexander Vainshtein wrote:

David, Nitin and = all,
 
IMHO the problem raised is specific because it = represents a=20 combination of situations:
  1. Handling of a non-planned event is required
    • From my experience, card failures fail quite often into = this=20 category

This is a generic problem.

    • Since the ecent is non-planned, the BFD machine cannot = prepare the=20 peer for this event. Handling of planned events could, e.g., = begin with=20 the peer expecting
    • such an event decalring the BFD session administratively = down and=20 thus precluding any undesirable action by the=20 peer

This is also a generic problem.

  1. The event affects the authentication procedure. This means = (and my=20 reading of the draft) that regardless of what the BFD machine = after the=20 event tries to do, it will not be achieved because the packets it = sends=20 shall not be authenticated and hence shall not affect the peer=20 behavior.

Again, this is no different if other "helping" BFD processes = didn't have=20 any of the session state. Any BFD information given w/ unknown session = information is ignored. This isn't limited to Auth.

The real-time side of the story (namely sequence numbers chagning = quite=20 fast) makes any solution based on synchronization between tow = incarnations=20 (before and after the event) of the BFD machine very difficult.



Difficult but, not impossible. Again, there are multiple = interoperable=20 implementations that work over enet bundles, MLPP, etc. Fortunately = none of=20 them change the packets on the wire or protocol state machine.

-DWard



Regards,

=

           &nbs= p;    =20 Sasha

From: David Ward = [mailto:dward@cisco.com]
Sent:=20 Fri 1/11/2008 1:39 AM
To: Nitin Bahadur
Cc: = David Ward;=20 Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor=20 Danilovich
Subject: Re: Resetting the sequence number in = an=20 authenticated BFD session

The solution for this is outside the scope of the spec. =  Note that=20 the problem you describe is not specific to auth at all, it is a = generic=20 system problem. The problem is the same if you receive any BFD = notification=20 over any link and you need to disseminate that information to all = component=20 links. Discrim change, timer change, etc they all fit into this = category.=20

You can home the BFD machine on one LC (yes, a form of = centralization)=20 and fwd bfd packets to it, you can run BFD on all LCs homing = component links=20 and send notifications between them (proprietary solution) - there = are many=20 variants of this. It is much, much harder to put the solution into=20 forwarding chips themselves but, again it is not an unsolvable = problem=20 either.

In any event, the meta point is that this problem is not = limited to=20 authentication seq_id rollover and unfort is not a solution that = requires=20 specification for interoperability. Towards that end I know of = multiple=20 interoperable implementations that work over bundles.

-DWard 

On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote:
 
The = case I was thinking of was = as=20 follows..
 
      =20 ____________  =20 =             &= nbsp;           &n= bsp; ________
     =20 |    = Bundle       =20 | =20 =             &= nbsp;           &n= bsp;|  =20 Bundle |   
 A =20 +---------------------+ B ------ C  ------ D +------------+ E =  
     =20 |____________ |
 
A and E = are iBGP=20 peers. iBGP doesn’t know/care bout link bundling. The peers = establish a=20 BFD mhop session = between=20 them. The links A-B and D-E are link bundles. One cannot guarantee = that=20 the link bundle components will be on the same line-card. How can = one=20 maintain auth semantics if the line card on A hosting  the = BFD=20 session goes down.
 
 
 
Ø      run BFD on all = component links=20 independently
This solution does not = work for=20 multi-hop bfd sessions. If=20 the outgoing link for a mhop session is a = link-bundle, then=20 you would need to create a 1 session per component = link just=20 to monitor the health of a single bfd peer. Also, for a mhop session, if there are = link=20 bundles on both the peers, I’m not sure how it would=20 work.
 
 
DW: The=20 picture would be that the component links in an L2 bundle are = directly=20 adjacent.  In an L2 bundle situation where you want to test = each link=20  independently with bidir comms between two routers why would = it be=20 mhop? MHop session = are for=20 those w/o being = directly=20 adjacent.
 
 
DW: Perhaps=20 you meant that two routers running a mhop BFD session that traversed = a link=20 bundle somewhere inbetween. In this case there is nothing you = can do as=20 there is nothing you can to to guarantee you are going to = traverse the same component = links of the=20 bundle inbetween two other routers. The forwarding choice of how = to=20 balance those flows over the=20 component links is a local decision that the mhop BFD'ing routers = cannot=20 bias.
 
 


= ------=_NextPart_000_032E_01C85439.C77AEC10-- From rtg-bfd-bounces@ietf.org Fri Jan 11 14:11:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPI4-0001Zl-16; Fri, 11 Jan 2008 14:11:40 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDPI2-0001X7-Ht for rtg-bfd-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 14:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPI2-0001Ua-6K for rtg-bfd@ietf.org; Fri, 11 Jan 2008 14:11:38 -0500 Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDPI0-0002ma-N9 for rtg-bfd@ietf.org; Fri, 11 Jan 2008 14:11:38 -0500 Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 11 Jan 2008 11:11:29 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jan 2008 11:09:29 -0800 Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m0BJ9T922372; Fri, 11 Jan 2008 11:09:29 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 1 Content-Type: multipart/alternative; boundary=Apple-Mail-19-580552696 Message-Id: <1A38C490-BC35-4ACA-A138-A93A03A99BE6@juniper.net> From: Dave Katz Date: Fri, 11 Jan 2008 12:09:28 -0700 To: Alexander Vainshtein X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 11 Jan 2008 19:09:29.0859 (UTC) FILETIME=[7DD58D30:01C85485] X-Spam-Score: -4.0 (----) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: Ronen Sommer , BFD WG , Igor Danilovich , David Ward Subject: Re: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-19-580552696 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I am not a security expert, nor do I play one on TV, but the whole point of the sequence number scheme is to protect against replay attacks, and any scheme that allows for the arbitrary resetting of the sequence number space opens up a giant hole. If the authentication section were to carry an additional field with "next sequence number expected" then the sender who had lost track of the sequence space could recover without the receiver being vulnerable to a replay attack (the details of making this work properly with multiple packets in flight seems possible with sufficient signaling but is beyond my ability to extemporize in this email.) Note that I believe it is impossible to avoid session flapping in the case where the round-trip time between systems is greater than the detection time of the session, so it's not clear that any such solution is possible in the general case. If people feel strongly enough about this issue and cannot solve it any other way, I would suggest an extension to the base spec using a new authentication type field, as this is going to take some time and careful thought, and could be done without affecting the base spec. It's worth noting, however, that this is mostly just a particular instance of the more general problem of recovering from lost BFD state. Another interesting example is trying to handle various graceful-restart-like scenarios, including processor failover. The generic solution to these problems is to add a layer between the BFD state machine and the applications that does some intelligent hysteresis around BFD state changes and hides the flap from the applications. This can easily be done without impacting the detection time of the session for cases other than the sequence number issue. The long-overdue reissue of the generic spec will talk about this more fully, Real Soon Now. It's a little bit touchier to pull off with the sequence number stuff because it's hard to reestablish session state in less than a detection time. One straightforward approach would be to simply wait for the old session to time out (since you'll be receiving packets that don't authenticate.) This complicates the heuristics of the flap suppression a bit, but not terribly, and it also means that signaling session failure to applications when the far end key stops working will take longer than a detection time. This doesn't sound like a bad tradeoff to me, since it's a deep-end case and wouldn't impact the detection time for generic failures. The security implications are exactly what they are today for session establishment (or slightly better, since any bad-guy third party would have to block the legitimate session as well as replaying the establishment of a new one.) Another scheme could involve establishing a new session and abandoning the old one, which could be done in less than a detection time, but this opens up a giant denial-of-service hole. --Dave On Jan 10, 2008, at 1:42 PM, Alexander Vainshtein wrote: > Hi all, > I have a question related to the expected behavior of sequence > numbers in an aythenticated (MD5 or SHA1) BFD session. > > The corresdponding sections of draft-ietf-bfd-base-06 state that, > once the packet has been authenticated by the receiver, its > sequence number MUST be checked; if its value is out of range > defined by the last received sequence number and the Detect > Multiplexor, the packet MUST be discarded. > > This may result in the a BFD session going down in the situation > when the transceiver "loses" the information about its last > transmitted sequence number. A suitable use case is a multilink > interface (LAG, ML-PPP, etc.) with the links residing in different > line cards, and e BFD implemented in one of these cards: if this > card fails, the BFD would could be re-started in one of the > remaining cards. Such a restart would not affect the local session > because the BFD machine would be restarted with bfd.AuthSeqKnown = > 0, but keeping bfd.XmitAuthSeq consistent between different line > cards seems problematic. (Implemeting BFD in some common card would > resolve the situation with the multilink interfaces but would raise > similar issues when the common card fails). > > Note that this problem would not occur for a non-authenticated BFD > session. > > IMHO this problem is real, and I do not see a simple solution for it. > I would highly appreciate any feedback from the draft authors and/ > or from the WG. > > Regards, > Sasha > --Apple-Mail-19-580552696 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I am not a security expert, nor do I play one on TV, but the whole = point of the sequence number scheme is to protect against replay = attacks, and any scheme that allows for the arbitrary resetting of the = sequence number space opens up a giant hole.

If the authentication = section were to carry an additional field with "next sequence number = expected" then the sender who had lost track of the sequence space could = recover without the receiver being vulnerable to a replay attack (the = details of making this work properly with multiple packets in flight = seems possible with sufficient signaling but is beyond my ability to = extemporize in this email.) =A0Note that I believe it is impossible to = avoid session flapping in the case where the round-trip time between = systems is greater than the detection time of the session, so it's not = clear that any such solution is possible in the general = case.

If = people feel strongly enough about this issue and cannot solve it any = other way, I would suggest an extension to the base spec using a new = authentication type field, as this is going to take some time and = careful thought, and could be done without affecting the base = spec.


It's worth noting, however, = that this is mostly just a particular instance of the more general = problem of recovering from lost BFD state. =A0Another interesting = example is trying to handle various graceful-restart-like scenarios, = including processor failover.

The generic solution to = these problems is to add a layer between the BFD state machine and the = applications that does some intelligent hysteresis around BFD state = changes and hides the flap from the applications. =A0This can easily be = done without impacting the detection time of the session for cases other = than the sequence number issue. =A0The long-overdue reissue of the = generic spec will talk about this more fully, Real Soon = Now.

It's a = little bit touchier to pull off with the sequence number stuff because = it's hard to reestablish session state in less than a detection time. = =A0One straightforward approach would be to simply wait for the old = session to time out (since you'll be receiving packets that don't = authenticate.) =A0This complicates the heuristics of the flap = suppression a bit, but not terribly, and it also means that signaling = session failure to applications when the far end key stops working will = take longer than a detection time. =A0This doesn't sound like a bad = tradeoff to me, since it's a deep-end case and wouldn't impact the = detection time for generic failures. =A0The security implications are = exactly what they are today for session establishment (or slightly = better, since any bad-guy third party would have to block the legitimate = session as well as replaying the establishment of a new = one.)

Another = scheme could involve establishing a new session and abandoning the old = one, which could be done in less than a detection time, but this opens = up a giant denial-of-service hole.

--Dave


On = Jan 10, 2008, at 1:42 PM, Alexander Vainshtein wrote:

=
Hi = all,
I have a question = related to the expected behavior of sequence numbers in an aythenticated = (MD5 or SHA1) BFD session.
=A0
The = corresdponding sections of draft-ietf-bfd-base-06 state that, once the = packet has been authenticated by the receiver, its sequence number MUST = be checked; if its value is out of range defined by the last received = sequence number and the Detect Multiplexor, the packet MUST be = discarded.
=A0
This = may result in the a BFD session going down in the situation when the = transceiver "loses" the information about its last transmitted sequence = number. A suitable=A0use case=A0is a multilink interface (LAG, ML-PPP, = etc.) with the links residing in different=A0line=A0cards, and e BFD = implemented in one of these cards:=A0if this card=A0fails, the BFD = would=A0could be re-started in one of the remaining cards. Such a = restart would not affect the local=A0session because=A0the BFD=A0machine = would=A0be restarted with bfd.AuthSeqKnown =3D 0, but = keeping bfd.XmitAuthSeq consistent between different = line cards seems problematic. (Implemeting BFD in some common card would = resolve the situation with the multilink interfaces but would raise = similar issues when the common card fails).
=A0
=
Note that this problem would not = occur=A0for a non-authenticated BFD session.
=A0
=
IMHO this problem is real, and I do = not see a simple solution for it.=A0
I would highly appreciate any feedback from = the draft authors and/or from the WG.
=A0
Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Sasha
=A0

= --Apple-Mail-19-580552696-- From rtg-bfd-bounces@ietf.org Sun Jan 13 00:24:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDvKk-0000pf-45; Sun, 13 Jan 2008 00:24:34 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDvKi-0000pK-91 for rtg-bfd-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 00:24:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDvKh-0000pC-ST for rtg-bfd@ietf.org; Sun, 13 Jan 2008 00:24:31 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDvKe-0003gY-Ef for rtg-bfd@ietf.org; Sun, 13 Jan 2008 00:24:31 -0500 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 13 Jan 2008 07:42:38 +0200 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Jan 2008 07:24:27 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Sun, 13 Jan 2008 07:24:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C855A4.9046AE3A" Date: Sun, 13 Jan 2008 07:24:26 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD0252D70D@ILPTEX02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchUXPIucBpc3dkLRNyDTb539l4jagBRflBD References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <64122293A6365B4A9794DC5636F9ACFD0252D70B@ILPTEX02.ecitele.com> From: Alexander Vainshtein To: "David Ward" X-OriginalArrivalTime: 13 Jan 2008 05:24:27.0520 (UTC) FILETIME=[90F79000:01C855A4] X-Spam-Score: 1.8 (+) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: BFD WG , Ronen Sommer , Igor Danilovich , Dave Katz Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------_=_NextPart_001_01C855A4.9046AE3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, I have probably poorly presented the case of an intermediate L2 device.=20 What I have in mind is the following combination: 1.=09 A single L3 adjacency monitored by BFD that has been established across = an intermediate L2 device 2.=09 Different number of L2-bundled links between each of the L3 peers and = the intermediate L2 device. I do not see how your proposed solutions would help to resolve the = problem: 1. Not sure why UDLR is relevant to this scenario, will look-up the = appropriate RFC first 2. LACP operates per L2-bundled link. It would help to detect a failure = of such a link, but, IMHO, no more than that 3. L3 BFD between a L3 and L2 device would not affect the state of the = L3 BFD session between the L3 peers. Regards, Sasha ________________________________ From: David Ward [mailto:dward@cisco.com] Sent: Fri 1/11/2008 4:18 PM To: Alexander Vainshtein Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD = session Sasha -=20 I think I already covered your points on centralization and master = component link. WRT the issue that a L3 device is connected to an L2 = device via a bundled interface and the far L3 device is single attached = ... BFD is currently an L3 solution. You'd have to run LACP, UDLR or BFD = at L3 to the L2 device to cover this scenario. -DWard On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote: David, Nitin and all, Please see inline below (blue italics)..Unfortunately it seems that = none of the options explicitly proposed by David resolve the issue. =20 Regards, Sasha ________________________________ From: David Ward [mailto:dward@cisco.com] Sent: Thu 1/10/2008 11:51 PM To: Nitin Bahadur Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; = Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD = session =09 =09 Solutions include (and are alluded to in the drafts):=20 run BFD on bundled interfaces (any flavor) centrally [Sasha] This = rasies the issue of the central component failover (as mentioned in my = oriinal message). =20 run BFD on all component links independently [Sasha] IMHO this is not a = viable option. E.g., consider a L3 1-hop situation where the bundled = interfaces run between one of the routers and a L2 switch, while the L3 = adjacency is unaware of bundling. This is easily achieved with LAG.=20 =20 run BFD on a master component link [Sasha] The failure of the LC that = carries the "master componet link" is the original scenario described in = my original email, and the issue remains unsloved IMO. There are other variants as well. -DWard On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: =09 Alexander, =20 I agree that keeping the sequence number consistent between line = cards is not practical. We need a way for a system to indicate that it = wants to restart the sequence. =20 Nitin =20 =09 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, January 10, 2008 12:42 PM To: David Ward; Dave Katz Cc: Ronen Sommer; BFD WG; Igor Danilovich Subject: Resetting the sequence number in an authenticated BFD session Importance: High =20 Hi all, I have a question related to the expected behavior of sequence numbers = in an aythenticated (MD5 or SHA1) BFD session. =20 The corresdponding sections of draft-ietf-bfd-base-06 state that, once = the packet has been authenticated by the receiver, its sequence number = MUST be checked; if its value is out of range defined by the last = received sequence number and the Detect Multiplexor, the packet MUST be = discarded. =20 This may result in the a BFD session going down in the situation when = the transceiver "loses" the information about its last transmitted = sequence number. A suitable use case is a multilink interface (LAG, = ML-PPP, etc.) with the links residing in different line cards, and e BFD = implemented in one of these cards: if this card fails, the BFD would = could be re-started in one of the remaining cards. Such a restart would = not affect the local session because the BFD machine would be restarted = with bfd.AuthSeqKnown =3D 0, but keeping bfd.XmitAuthSeq consistent = between different line cards seems problematic. (Implemeting BFD in some = common card would resolve the situation with the multilink interfaces = but would raise similar issues when the common card fails). =20 Note that this problem would not occur for a non-authenticated BFD = session. =20 IMHO this problem is real, and I do not see a simple solution for it.=20 I would highly appreciate any feedback from the draft authors and/or = from the WG. =20 Regards, Sasha =20 ------_=_NextPart_001_01C855A4.9046AE3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
David,
=0A=
I have probably poorly = presented the case of an intermediate L2 device.
=0A=
What I have in mind is the = following combination:
=0A=
=0A=
    =0A=
  1. =0A=
    A single L3 adjacency monitored by = BFD that has been established across an intermediate L2 = device
    2. =0A=
  2. =0A=
    Different number of L2-bundled links = between each of the L3 peers and the intermediate L2 = device.
=0A=

I do not see how your proposed solutions = would help to resolve the problem:

=0A=
    =0A=
  1. Not sure why UDLR is relevant to this = scenario, will look-up the appropriate RFC first
    2. =0A=
  2. LACP operates per L2-bundled link. It = would help to detect a failure of such a link, but, IMHO, no more = than that
    3. =0A=
  3. L3 BFD between a L3 and L2 device would = not affect the state of the L3 BFD session between the L3 = peers.
=0A=

Regards,

=0A=

          &nbs= p;     Sasha

=0A=

=0A=
=0A=
=0A=
=0A=
From: David Ward = [mailto:dward@cisco.com]
Sent: Fri 1/11/2008 4:18 = PM
To: Alexander Vainshtein
Cc: David Ward; Nitin = Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
Subject: Re: Resetting the sequence number in an = authenticated BFD session

=0A= ------_=_NextPart_001_01C855A4.9046AE3A-- From rtg-bfd-bounces@ietf.org Sun Jan 13 00:44:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDvdk-0008Jq-Ef; Sun, 13 Jan 2008 00:44:12 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDvdi-0008Jk-8e for rtg-bfd-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 00:44:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDvdh-0008Jc-Rw for rtg-bfd@ietf.org; Sun, 13 Jan 2008 00:44:09 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDvdg-0002Sc-1N for rtg-bfd@ietf.org; Sun, 13 Jan 2008 00:44:09 -0500 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 13 Jan 2008 08:02:17 +0200 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Jan 2008 07:44:06 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Sun, 13 Jan 2008 07:44:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C855A7.4F147E30" Date: Sun, 13 Jan 2008 07:44:05 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD0252D70E@ILPTEX02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchUhcqY3J/aQWI7S+6ZfNwqFVkAswBHs2T1 References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <1A38C490-BC35-4ACA-A138-A93A03A99BE6@juniper.net> From: Alexander Vainshtein To: "Dave Katz" X-OriginalArrivalTime: 13 Jan 2008 05:44:06.0589 (UTC) FILETIME=[4FBF36D0:01C855A7] X-Spam-Score: 1.8 (+) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: Ronen Sommer , BFD WG , Igor Danilovich , David Ward Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------_=_NextPart_001_01C855A7.4F147E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, Lots of thanks for a detailed response. Please see inline below (blue = italics). =20 Regards, Sasha ________________________________ From: Dave Katz [mailto:dkatz@juniper.net] Sent: Fri 1/11/2008 9:09 PM To: Alexander Vainshtein Cc: David Ward; BFD WG; Igor Danilovich; Ronen Sommer Subject: Re: Resetting the sequence number in an authenticated BFD = session I am not a security expert, nor do I play one on TV, but the whole point = of the sequence number scheme is to protect against replay attacks, and = any scheme that allows for the arbitrary resetting of the sequence = number space opens up a giant hole. [Sasha] I am not a security expert either, but I understand that = allowing arbitrary resetting of the sequence number would be a serious = security issue. This was the main reason behind the statement (in the = original message) that "I do not see a simple solution for the problem". If the authentication section were to carry an additional field with = "next sequence number expected" then the sender who had lost track of = the sequence space could recover without the receiver being vulnerable = to a replay attack (the details of making this work properly with = multiple packets in flight seems possible with sufficient signaling but = is beyond my ability to extemporize in this email.) Note that I believe = it is impossible to avoid session flapping in the case where the = round-trip time between systems is greater than the detection time of = the session, so it's not clear that any such solution is possible in the = general case. [Sasha] I agree that this is at least very complicated and = probably impossible. If people feel strongly enough about this issue and cannot solve it any = other way, I would suggest an extension to the base spec using a new = authentication type field, as this is going to take some time and = careful thought, and could be done without affecting the base spec. = [Sasha] This would be nice. Not sure, though, how strong the people feel = about it. One piece of info that could help is the understanding of the = actual usage of the BFD authentication in the real-life deployments.=20 It's worth noting, however, that this is mostly just a particular = instance of the more general problem of recovering from lost BFD state. = Another interesting example is trying to handle various = graceful-restart-like scenarios, including processor failover.=20 The generic solution to these problems is to add a layer between the BFD = state machine and the applications that does some intelligent hysteresis = around BFD state changes and hides the flap from the applications. This = can easily be done without impacting the detection time of the session = for cases other than the sequence number issue. The long-overdue = reissue of the generic spec will talk about this more fully, Real Soon = Now. It's a little bit touchier to pull off with the sequence number stuff = because it's hard to reestablish session state in less than a detection = time. One straightforward approach would be to simply wait for the old = session to time out (since you'll be receiving packets that don't = authenticate.) This complicates the heuristics of the flap suppression = a bit, but not terribly, and it also means that signaling session = failure to applications when the far end key stops working will take = longer than a detection time. This doesn't sound like a bad tradeoff to = me, since it's a deep-end case and wouldn't impact the detection time = for generic failures. The security implications are exactly what they = are today for session establishment (or slightly better, since any = bad-guy third party would have to block the legitimate session as well = as replaying the establishment of a new one.) Another scheme could involve establishing a new session and abandoning = the old one, which could be done in less than a detection time, but this = opens up a giant denial-of-service hole. --Dave On Jan 10, 2008, at 1:42 PM, Alexander Vainshtein wrote: Hi all, I have a question related to the expected behavior of sequence numbers = in an aythenticated (MD5 or SHA1) BFD session. =20 The corresdponding sections of draft-ietf-bfd-base-06 state that, once = the packet has been authenticated by the receiver, its sequence number = MUST be checked; if its value is out of range defined by the last = received sequence number and the Detect Multiplexor, the packet MUST be = discarded. =20 This may result in the a BFD session going down in the situation when = the transceiver "loses" the information about its last transmitted = sequence number. A suitable use case is a multilink interface (LAG, = ML-PPP, etc.) with the links residing in different line cards, and e BFD = implemented in one of these cards: if this card fails, the BFD would = could be re-started in one of the remaining cards. Such a restart would = not affect the local session because the BFD machine would be restarted = with bfd.AuthSeqKnown =3D 0, but keeping bfd.XmitAuthSeq consistent = between different line cards seems problematic. (Implemeting BFD in some = common card would resolve the situation with the multilink interfaces = but would raise similar issues when the common card fails). =20 Note that this problem would not occur for a non-authenticated BFD = session. =20 IMHO this problem is real, and I do not see a simple solution for it.=20 I would highly appreciate any feedback from the draft authors and/or = from the WG. =20 Regards, Sasha =20 ------_=_NextPart_001_01C855A7.4F147E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Dave,
=0A=
Lots of thanks for a detailed = response. Please see inline below (blue italics).
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;        Sasha
=0A=

=0A=
=0A= From: Dave Katz = [mailto:dkatz@juniper.net]
Sent: Fri 1/11/2008 9:09 = PM
To: Alexander Vainshtein
Cc: David Ward; BFD WG; = Igor Danilovich; Ronen Sommer
Subject: Re: Resetting the = sequence number in an authenticated BFD session

=0A=
=0A=
I am not a security expert, nor do I play one on TV, but the whole = point of the sequence number scheme is to protect against replay = attacks, and any scheme that allows for the arbitrary resetting of the = sequence number space opens up a giant hole.
=0A=
[Sasha] I am not a security expert = either, but I understand that allowing arbitrary resetting of the = sequence number would be a serious security issue. This was the main = reason behind the statement (in the original message) that "I do not see = a simple solution for the problem".
=0A=

=0A=
If the authentication section were to carry an additional field = with "next sequence number expected" then the sender who had lost track = of the sequence space could recover without the receiver being = vulnerable to a replay attack (the details of making this work properly = with multiple packets in flight seems possible with sufficient signaling = but is beyond my ability to extemporize in this email.)  Note that = I believe it is impossible to avoid session flapping in the case where = the round-trip time between systems is greater than the detection time = of the session, so it's not clear that any such solution is possible in = the general case. [Sasha] I agree that this is = at least very complicated and probably impossible.
=0A=

=0A=
If people feel strongly enough about this issue and cannot solve it = any other way, I would suggest an extension to the base spec using a new = authentication type field, as this is going to take some time and = careful thought, and could be done without affecting the base spec. = [Sasha] This would be nice. Not sure, though, = how strong the people feel about it. One piece of info that could help = is the understanding of the actual usage of the BFD authentication in = the real-life deployments.
=0A=

=0A=

It's worth noting, = however, that this is mostly just a particular instance of the more = general problem of recovering from lost BFD state.  Another = interesting example is trying to handle various graceful-restart-like = scenarios, including processor failover. =0A=

=0A=
The generic solution to these problems is to add a layer between = the BFD state machine and the applications that does some intelligent = hysteresis around BFD state changes and hides the flap from the = applications.  This can easily be done without impacting the = detection time of the session for cases other than the sequence number = issue.  The long-overdue reissue of the generic spec will talk = about this more fully, Real Soon Now.
=0A=

=0A=
It's a little bit touchier to pull off with the sequence number = stuff because it's hard to reestablish session state in less than a = detection time.  One straightforward approach would be to simply = wait for the old session to time out (since you'll be receiving packets = that don't authenticate.)  This complicates the heuristics of the = flap suppression a bit, but not terribly, and it also means that = signaling session failure to applications when the far end key stops = working will take longer than a detection time.  This doesn't sound = like a bad tradeoff to me, since it's a deep-end case and wouldn't = impact the detection time for generic failures.  The security = implications are exactly what they are today for session establishment = (or slightly better, since any bad-guy third party would have to block = the legitimate session as well as replaying the establishment of a new = one.)
=0A=

=0A=
Another scheme could involve establishing a new session and = abandoning the old one, which could be done in less than a detection = time, but this opens up a giant denial-of-service hole.
=0A=

=0A=
--Dave
=0A=

=0A=

=0A=
=0A=
=0A=
On Jan 10, 2008, at 1:42 PM, Alexander Vainshtein wrote:

=0A=
=0A=
Hi all,
=0A=
I have a question related to the = expected behavior of sequence numbers in an aythenticated (MD5 or SHA1) = BFD session.
=0A=
 
=0A=
The corresdponding sections of = draft-ietf-bfd-base-06 state that, once the packet has been = authenticated by the receiver, its sequence number MUST be checked; if = its value is out of range defined by the last received sequence number = and the Detect Multiplexor, the packet MUST be discarded.
=0A=
 
=0A=
This may result in the a BFD session = going down in the situation when the transceiver "loses" the information = about its last transmitted sequence number. A suitable use = case is a multilink interface (LAG, ML-PPP, etc.) with the links = residing in different line cards, and e BFD implemented in one = of these cards: if this card fails, the BFD would could = be re-started in one of the remaining cards. Such a restart would not = affect the local session because the BFD machine = would be restarted with bfd.AuthSeqKnown =3D 0, but = keeping bfd.XmitAuthSeq consistent between different = line cards seems problematic. (Implemeting BFD in some common card would = resolve the situation with the multilink interfaces but would raise = similar issues when the common card fails).
=0A=
 
=0A=
Note that this problem would not = occur for a non-authenticated BFD session.
=0A=
 
=0A=
IMHO this problem is real, and I do not = see a simple solution for it. 
=0A=
I would highly appreciate any feedback = from the draft authors and/or from the WG.
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;       Sasha
=0A=
 

------_=_NextPart_001_01C855A7.4F147E30-- From rtg-bfd-bounces@ietf.org Sun Jan 13 11:18:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE5X8-0007D0-OY; Sun, 13 Jan 2008 11:18:02 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JE5X7-0007Cr-Jb for rtg-bfd-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 11:18:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE5X7-0007Cj-6K for rtg-bfd@ietf.org; Sun, 13 Jan 2008 11:18:01 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE5X5-00022U-7Y for rtg-bfd@ietf.org; Sun, 13 Jan 2008 11:18:01 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2008 08:17:57 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0DGHuqY015641; Sun, 13 Jan 2008 11:17:56 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0DGHuN6022448; Sun, 13 Jan 2008 16:17:56 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Jan 2008 11:17:56 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Jan 2008 11:17:54 -0500 In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252D70D@ILPTEX02.ecitele.com> References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <64122293A6365B4A9794DC5636F9ACFD0252D70B@ILPTEX02.ecitele.com> <64122293A6365B4A9794DC5636F9ACFD0252D70D@ILPTEX02.ecitele.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: multipart/alternative; boundary=Apple-Mail-2-743049712 Message-Id: <37AA0457-0AC7-4C00-975F-96416C050870@cisco.com> From: David Ward Date: Sun, 13 Jan 2008 10:17:45 -0600 To: Alexander Vainshtein X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 13 Jan 2008 16:17:54.0462 (UTC) FILETIME=[DA2023E0:01C855FF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24369; t=1200241076; x=1201105076; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20Resetting=20the=20sequence=20number=20i n=20an=20authenticated=20BFD=20session |Sender:=20 |To:=20Alexander=20Vainshtein=20; bh=HNsF/XrxfhM5XciKw4PofRb23hK5ELSkgwIobW6B6IE=; b=BzFrSJG6Lf1DfvotHf0VDSQTtYkxBBAzWE8FVTi/08wQOf/evcX8mXVo/3 8NKu6IOpK4yNL8OlOjY9RlMrmDmO3DBEgKguk/Kuwg7SQ3JrBf4wdiksDXa/ 916dNR8MWR; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Cc: Ronen Sommer , Dave Katz , Igor Danilovich , David Ward , BFD WG Subject: Re: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-2-743049712 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Sasha - What you need to realize is that you have a layering problem to solve and one could solve it multiple ways today. One solution: Run LACP or UDLD between the router and the switch that has the bundled interface, monitor component links and the state of the bundle. Independently run a BFD session between the two routers. Second solution: Run BFD between the two routers and on the router with the bundled interface, have a distributed state machine on all cards that home component links (this is an implementation specific design). Third solution: Run BFD between the router and the switch with the bundled interface via IP and monitor all component links. Run a second BFD between the two routers and use either a centralized BFD, a master link (that can receive all BFD packets through internal forwarding) or replicate state via #2. All three of the above solve the problem (there are obvious variants) and are deployed today. -DWard On Jan 12, 2008, at 11:24 PM, Alexander Vainshtein wrote: > David, > I have probably poorly presented the case of an intermediate L2 > device. > What I have in mind is the following combination: > A single L3 adjacency monitored by BFD that has been established > across an intermediate L2 device > Different number of L2-bundled links between each of the L3 peers > and the intermediate L2 device. > I do not see how your proposed solutions would help to resolve the > problem: > > Not sure why UDLR is relevant to this scenario, will look-up the > appropriate RFC first > LACP operates per L2-bundled link. It would help to detect a > failure of such a link, but, IMHO, no more than that > L3 BFD between a L3 and L2 device would not affect the state of the > L3 BFD session between the L3 peers. > > Regards, > > Sasha > > > From: David Ward [mailto:dward@cisco.com] > Sent: Fri 1/11/2008 4:18 PM > To: Alexander Vainshtein > Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; > Igor Danilovich > Subject: Re: Resetting the sequence number in an authenticated BFD > session > > Sasha - > > > I think I already covered your points on centralization and master > component link. WRT the issue that a L3 device is connected to an > L2 device via a bundled interface and the far L3 device is single > attached ... BFD is currently an L3 solution. You'd have to run > LACP, UDLR or BFD at L3 to the L2 device to cover this scenario. > > -DWard > > > On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote: > >> David, Nitin and all, >> Please see inline below (blue italics)..Unfortunately it seems >> that none of the options explicitly proposed by David resolve the >> issue. >> >> Regards, >> Sasha >> >> From: David Ward [mailto:dward@cisco.com] >> Sent: Thu 1/10/2008 11:51 PM >> To: Nitin Bahadur >> Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD >> WG; Igor Danilovich >> Subject: Re: Resetting the sequence number in an authenticated BFD >> session >> >> Solutions include (and are alluded to in the drafts): >> >> run BFD on bundled interfaces (any flavor) centrally [Sasha] This >> rasies the issue of the central component failover (as mentioned >> in my oriinal message). >> >> run BFD on all component links independently [Sasha] IMHO this is >> not a viable option. E.g., consider a L3 1-hop situation where the >> bundled interfaces run between one of the routers and a L2 switch, >> while the L3 adjacency is unaware of bundling. This is easily >> achieved with LAG. >> >> run BFD on a master component link [Sasha] The failure of the LC >> that carries the "master componet link" is the original scenario >> described in my original email, and the issue remains unsloved IMO. >> >> There are other variants as well. >> >> -DWard >> >> On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: >> >>> Alexander, >>> >>> I agree that keeping the sequence number consistent between >>> line cards is not practical. We need a way for a system to >>> indicate that it wants to restart the sequence. >>> >>> Nitin >>> >>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >>> Sent: Thursday, January 10, 2008 12:42 PM >>> To: David Ward; Dave Katz >>> Cc: Ronen Sommer; BFD WG; Igor Danilovich >>> Subject: Resetting the sequence number in an authenticated BFD >>> session >>> Importance: High >>> >>> Hi all, >>> I have a question related to the expected behavior of sequence >>> numbers in an aythenticated (MD5 or SHA1) BFD session. >>> >>> The corresdponding sections of draft-ietf-bfd-base-06 state that, >>> once the packet has been authenticated by the receiver, its >>> sequence number MUST be checked; if its value is out of range >>> defined by the last received sequence number and the Detect >>> Multiplexor, the packet MUST be discarded. >>> >>> This may result in the a BFD session going down in the situation >>> when the transceiver "loses" the information about its last >>> transmitted sequence number. A suitable use case is a multilink >>> interface (LAG, ML-PPP, etc.) with the links residing in >>> different line cards, and e BFD implemented in one of these >>> cards: if this card fails, the BFD would could be re-started in >>> one of the remaining cards. Such a restart would not affect the >>> local session because the BFD machine would be restarted with >>> bfd.AuthSeqKnown = 0, but keeping bfd.XmitAuthSeq consistent >>> between different line cards seems problematic. (Implemeting BFD >>> in some common card would resolve the situation with the >>> multilink interfaces but would raise similar issues when the >>> common card fails). >>> >>> Note that this problem would not occur for a non-authenticated >>> BFD session. >>> >>> IMHO this problem is real, and I do not see a simple solution for >>> it. >>> I would highly appreciate any feedback from the draft authors and/ >>> or from the WG. >>> >>> Regards, >>> Sasha >>> >> > --Apple-Mail-2-743049712 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Sasha -

What you = need to realize is that you have a layering problem to solve and one = could solve it multiple ways today.

One = solution:

Run = LACP or UDLD between the router and the switch that has the bundled = interface, monitor component links and the state of the bundle. = Independently run a BFD session between the two routers.=A0


Second = solution:

Run = BFD between the two routers and on the router with the bundled = interface, have a distributed state machine on all cards that home = component links (this is an implementation specific = design).


Third = solution:

Run = BFD between the router and the switch with the bundled interface via IP = and monitor all component links. Run a second BFD between the two = routers and use either a centralized BFD, a master link (that can = receive all BFD packets through internal forwarding) or replicate state = via #2.



All three of the above = solve the problem (there are obvious variants) and are deployed = today.

-DWard



On Jan 12, 2008, at 11:24 PM, Alexander Vainshtein wrote:

David,
I have probably poorly presented the case of an intermediate = L2 device.
What I have in mind is the following = combination:
  1. =
    A=A0single L3 adjacency monitored = by BFD that has been established across an intermediate=A0L2 = device
  2. Different number of L2-bundled links between each of the L3 = peers and the intermediate L2 = device.

I = do not see how your proposed solutions would help to resolve the = problem:

  1. Not sure = why UDLR is relevant to this scenario, will look-up the appropriate RFC = first
  2. LACP operates per = L2-bundled link. It would help to detect a failure of such a link, but, = IMHO,=A0no more than that



  • L3 BFD between a L3 = and L2 device would not affect the state of the L3 BFD session between = the L3 peers.






    • Regards,

    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Sasha


    From: David Ward [mailto:dward@cisco.com]
    Sent: Fri 1/11/2008 4:18 PM
    To: Alexander Vainshtein
    Cc: = David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
    Subject: Re: Resetting the sequence number in an = authenticated BFD session

    Sasha -


    I think I already covered = your points on centralization and master component link. WRT the issue = that a L3 device is connected to an L2 device via a bundled interface = and the far L3 device is single attached ... BFD is currently an L3 = solution. You'd have to run LACP, UDLR or BFD at L3 to the L2 device to = cover this scenario.

    -DWard


    On Jan = 11, 2008, at 4:11 AM, Alexander Vainshtein wrote:

    David, Nitin and = all,
    Please = see inline below (blue = italics)..Unfortunately it seems that none of the options = explicitly proposed by David resolve the issue.
    =A0
    Regards,
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Sasha

    From: David = Ward [mailto:dward@cisco.com]
    Sent: Thu 1/10/2008 11:51 PM
    To: Nitin Bahadur
    Cc: David = Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
    Subject: Re: Resetting the sequence number in an = authenticated BFD session

    Solutions include = (and are alluded to in the drafts):

    run BFD on bundled = interfaces (any flavor) centrally [Sasha] = This rasies the issue of the central component failover (as mentioned in = my oriinal message).
    =A0
    run BFD on = all component links independently [Sasha] = IMHO this is not a viable option. E.g., consider a L3 1-hop situation = where the bundled interfaces run between one of the routers and a L2 = switch, while the L3 adjacency is unaware of bundling. This is easily = achieved with LAG.
    =A0
    run BFD on a master = component link [Sasha] The failure of the LC = that carries the "master componet link" is the original scenario = described in my original email, and the issue remains unsloved = IMO.

    =
    There are other variants as well.

    -DWard

    =
    On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote:

    Alexander,
    =A0
    =A0=A0 I = agree that keeping the=A0sequence number consistent = between line cards is not practical. We need a way for a system to = indicate that it wants to restart the=A0sequence.
    =
    =A0
    Nitin
    =A0
    =
    =
    From:=A0Alexander Vainshtein [mailto:Alexander.Vainshte= in@ecitele.com]=A0
    Sent:=A0Thursday, January 10, 2008 = 12:42 PM
    To:=A0David Ward;=A0Dave Katz
    Cc:=A0Ronen Sommer; BFD WG; Igor = Danilovich
    Subject:=A0Resetting the=A0sequence number in an = authenticated BFD=A0session
    Importance:=A0High
    =
    =A0
    Hi = all,
    I have a = question related to the expected behavior of=A0sequence numbers in an = aythenticated (MD5 or SHA1) BFD=A0session.
    =A0
    =
    The corresdponding=A0sections of = draft-ietf-bfd-base-06 state that, once the packet has been = authenticated by the receiver, its=A0sequence number MUST be = checked; if its value is out of range defined by the last received=A0sequence number and the Detect = Multiplexor, the packet MUST be discarded.
    =
    =A0
    This may result in the a BFD=A0session going down in the = situation when the transceiver "loses" the information about its last = transmitted=A0sequence = number. A suitable=A0use=A0case=A0is a multilink = interface (LAG, ML-PPP, etc.) with the links residing in = different=A0line=A0cards, and e BFD implemented in one of these=A0cards:=A0if this card=A0fails, = the BFD would=A0could be re-started in one of the remaining cards. Such = a restart would not affect the local=A0session because=A0the BFD=A0machine= would=A0be restarted with=A0bfd.AuthSeqKnown=A0=3D = 0, but keeping=A0bfd.XmitAuthSeq=A0consistent between different = line cards=A0seems = problematic. (Implemeting BFD in some common card would resolve the = situation with the multilink interfaces but would raise=A0similar issues when the common = card fails).
    =A0
    Note that = this problem would not occur=A0for a non-authenticated BFD=A0session.
    =A0
    =
    IMHO this problem is real, = and I do not=A0see a simple = solution for it.=A0
    I would highly appreciate any feedback from the = draft authors and/or from the WG.
    =A0
    Regards,
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Sasha
    =A0
    <= br>


    <= /div>= --Apple-Mail-2-743049712-- From rtg-bfd-bounces@ietf.org Sun Jan 13 12:17:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE6SP-0002hR-JN; Sun, 13 Jan 2008 12:17:13 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JE6SO-0002hJ-Dj for rtg-bfd-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 12:17:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE6SN-0002hB-Vc for rtg-bfd@ietf.org; Sun, 13 Jan 2008 12:17:12 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE6SL-00032h-Ca for rtg-bfd@ietf.org; Sun, 13 Jan 2008 12:17:11 -0500 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 13 Jan 2008 19:35:26 +0200 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Jan 2008 19:17:08 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Sun, 13 Jan 2008 19:17:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85608.1FF0EE3E" Date: Sun, 13 Jan 2008 19:17:06 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD02672A85@ILPTEX02.ecitele.com> In-Reply-To: <37AA0457-0AC7-4C00-975F-96416C050870@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resetting the sequence number in an authenticated BFD session Thread-Index: AchV/+GFD8u7CUsBTgCt4Y8Ruk6D+gABkLOg References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <64122293A6365B4A9794DC5636F9ACFD0252D70B@ILPTEX02.ecitele.com> <64122293A6365B4A9794DC5636F9ACFD0252D70D@ILPTEX02.ecitele.com> <37AA0457-0AC7-4C00-975F-96416C050870@cisco.com> From: Alexander Vainshtein To: "David Ward" X-OriginalArrivalTime: 13 Jan 2008 17:17:08.0248 (UTC) FILETIME=[2058D980:01C85608] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8403cbbf1773e27474a13192645c46f Cc: BFD WG , Ronen Sommer , Dave Katz Subject: RE: Resetting the sequence number in an authenticated BFD session X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------_=_NextPart_001_01C85608.1FF0EE3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David and all, Lots of thanks for a prompt and detailed response. =20 My gut feeling is that replicated state (or something like that) is part of all the approaches you've outlined, but I must carefully re-check this feeling. =20 Regards, Sasha ________________________________ From: David Ward [mailto:dward@cisco.com]=20 Sent: Sunday, January 13, 2008 6:18 PM To: Alexander Vainshtein Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD session Sasha -=20 What you need to realize is that you have a layering problem to solve and one could solve it multiple ways today. One solution: Run LACP or UDLD between the router and the switch that has the bundled interface, monitor component links and the state of the bundle. Independently run a BFD session between the two routers.=20 Second solution: Run BFD between the two routers and on the router with the bundled interface, have a distributed state machine on all cards that home component links (this is an implementation specific design). Third solution: Run BFD between the router and the switch with the bundled interface via IP and monitor all component links. Run a second BFD between the two routers and use either a centralized BFD, a master link (that can receive all BFD packets through internal forwarding) or replicate state via #2. All three of the above solve the problem (there are obvious variants) and are deployed today. -DWard On Jan 12, 2008, at 11:24 PM, Alexander Vainshtein wrote: David, I have probably poorly presented the case of an intermediate L2 device.=20 What I have in mind is the following combination: 1.=09 A single L3 adjacency monitored by BFD that has been established across an intermediate L2 device 2.=09 Different number of L2-bundled links between each of the L3 peers and the intermediate L2 device. I do not see how your proposed solutions would help to resolve the problem: 1. Not sure why UDLR is relevant to this scenario, will look-up the appropriate RFC first=20 2. LACP operates per L2-bundled link. It would help to detect a failure of such a link, but, IMHO, no more than that 3. L3 BFD between a L3 and L2 device would not affect the state of the L3 BFD session between the L3 peers. =09 Regards, Sasha ________________________________ From: David Ward [mailto:dward@cisco.com] Sent: Fri 1/11/2008 4:18 PM To: Alexander Vainshtein Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD session =09 =09 Sasha -=20 I think I already covered your points on centralization and master component link. WRT the issue that a L3 device is connected to an L2 device via a bundled interface and the far L3 device is single attached ... BFD is currently an L3 solution. You'd have to run LACP, UDLR or BFD at L3 to the L2 device to cover this scenario. -DWard On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote: David, Nitin and all, Please see inline below (blue italics)..Unfortunately it seems that none of the options explicitly proposed by David resolve the issue. =20 Regards, Sasha ________________________________ From: David Ward [mailto:dward@cisco.com] Sent: Thu 1/10/2008 11:51 PM To: Nitin Bahadur Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich Subject: Re: Resetting the sequence number in an authenticated BFD session =09 =09 Solutions include (and are alluded to in the drafts):=20 run BFD on bundled interfaces (any flavor) centrally [Sasha] This rasies the issue of the central component failover (as mentioned in my oriinal message). =20 run BFD on all component links independently [Sasha] IMHO this is not a viable option. E.g., consider a L3 1-hop situation where the bundled interfaces run between one of the routers and a L2 switch, while the L3 adjacency is unaware of bundling. This is easily achieved with LAG.=20 =20 run BFD on a master component link [Sasha] The failure of the LC that carries the "master componet link" is the original scenario described in my original email, and the issue remains unsloved IMO. There are other variants as well. -DWard On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote: =09 Alexander, =20 I agree that keeping the sequence number consistent between line cards is not practical. We need a way for a system to indicate that it wants to restart the sequence. =20 Nitin =20 =09 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, January 10, 2008 12:42 PM To: David Ward; Dave Katz Cc: Ronen Sommer; BFD WG; Igor Danilovich Subject: Resetting the sequence number in an authenticated BFD session Importance: High =20 Hi all, I have a question related to the expected behavior of sequence numbers in an aythenticated (MD5 or SHA1) BFD session. =20 The corresdponding sections of draft-ietf-bfd-base-06 state that, once the packet has been authenticated by the receiver, its sequence number MUST be checked; if its value is out of range defined by the last received sequence number and the Detect Multiplexor, the packet MUST be discarded. =20 This may result in the a BFD session going down in the situation when the transceiver "loses" the information about its last transmitted sequence number. A suitable use case is a multilink interface (LAG, ML-PPP, etc.) with the links residing in different line cards, and e BFD implemented in one of these cards: if this card fails, the BFD would could be re-started in one of the remaining cards. Such a restart would not affect the local session because the BFD machine would be restarted with bfd.AuthSeqKnown =3D 0, but keeping bfd.XmitAuthSeq consistent between different line cards seems problematic. (Implemeting BFD in some common card would resolve the situation with the multilink interfaces but would raise similar issues when the common card fails). =20 Note that this problem would not occur for a non-authenticated BFD session. =20 IMHO this problem is real, and I do not see a simple solution for it.=20 I would highly appreciate any feedback from the draft authors and/or from the WG. =20 Regards, Sasha =20 ------_=_NextPart_001_01C85608.1FF0EE3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    David=20 and all,
    Lots=20 of thanks for a prompt and detailed response.
     
    My gut=20 feeling is that replicated state (or something like that) is part of all = the=20 approaches you've outlined, but I must carefully  re-check = this=20 feeling.
     
    Regards,
           &nbs= p;       =20 Sasha

    From: David Ward = [mailto:dward@cisco.com]=20
    Sent: Sunday, January 13, 2008 6:18 PM
    To: = Alexander=20 Vainshtein
    Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen = Sommer; BFD=20 WG; Igor Danilovich
    Subject: Re: Resetting the sequence number = in an=20 authenticated BFD session

    Sasha -

    What you need to realize is that you have a layering problem to = solve and=20 one could solve it multiple ways today.

    One solution:

    Run LACP or UDLD between the router and the switch that has the = bundled=20 interface, monitor component links and the state of the bundle. = Independently=20 run a BFD session between the two routers. 


    Second solution:

    Run BFD between the two routers and on the router with the bundled=20 interface, have a distributed state machine on all cards that home = component=20 links (this is an implementation specific design).


    Third solution:

    Run BFD between the router and the switch with the bundled = interface via IP=20 and monitor all component links. Run a second BFD between the two = routers and=20 use either a centralized BFD, a master link (that can receive all BFD = packets=20 through internal forwarding) or replicate state via #2.



    All three of the above solve the problem (there are obvious = variants) and=20 are deployed today.

    -DWard


    Sasha - =0A=

    =0A=

    =0A=
    I think I already covered your points on centralization and master = component link. WRT the issue that a L3 device is connected to an L2 = device via a bundled interface and the far L3 device is single attached = ... BFD is currently an L3 solution. You'd have to run LACP, UDLR or BFD = at L3 to the L2 device to cover this scenario.
    =0A=

    =0A=
    -DWard
    =0A=

    =0A=

    =0A=
    =0A=
    On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote:

    =0A=
    =0A=
    =0A=
    David, Nitin = and all,
    =0A=
    Please see inline below = (blue italics)..Unfortunately it = seems that none of the options explicitly proposed by David resolve the = issue.
    =0A=
     
    =0A=
    Regards,
    =0A=
              &nbs= p;      Sasha
    =0A=

    =0A=
    =0A= From: David Ward [mailto:dward@cisco.com]
    Sent: Thu 1/10/2008 11:51 PM
    To: Nitin Bahadur
    Cc: = David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor = Danilovich
    Subject: Re: Resetting the sequence number in an = authenticated BFD session

    =0A=
    Solutions include (and are alluded to in the drafts): =0A=

    =0A=
    run BFD on bundled interfaces (any flavor) centrally [Sasha] This rasies the issue of the central component = failover (as mentioned in my oriinal message).
    =0A=
     
    =0A=
    run BFD on all component links independently [Sasha] IMHO this is not a viable option. E.g., consider = a L3 1-hop situation where the bundled interfaces run between one of the = routers and a L2 switch, while the L3 adjacency is unaware of bundling. = This is easily achieved with LAG.
    =0A=
     
    =0A=
    run BFD on a master component link [Sasha] The failure of the LC that carries the "master = componet link" is the original scenario described in my original email, = and the issue remains unsloved IMO.
    =0A=

    =0A=
    There are other variants as well.
    =0A=

    =0A=
    -DWard
    =0A=

    =0A=
    =0A=
    On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote:

    =0A=
    =0A=
    =0A=
    Alexander,
    =0A=
     
    =0A=
       I agree that keeping the sequence number consistent = between line cards is not practical. We need a way for a system to = indicate that it wants to restart the sequence.
    =0A=
     
    =0A=
    Nitin
    =0A=
     
    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    From: Alexander = Vainshtein [mailto:Alexander.Vainsht= ein@ecitele.com] 
    Sent: Thursday, January 10, 2008 = 12:42 PM
    To: David Ward; Dave Katz
    Cc: Ronen Sommer; BFD WG; Igor = Danilovich
    Subject: Resetting the sequence number in an = authenticated BFD session
    Importance: High
    =0A=
     
    =0A=
    =0A=
    Hi = all,
    =0A=
    =0A=
    I have a question related to the expected behavior = of sequence numbers in = an aythenticated (MD5 or SHA1) BFD session.
    =0A=
    =0A=
     
    =0A=
    =0A=
    The corresdponding sections of = draft-ietf-bfd-base-06 state that, once the packet has been = authenticated by the receiver, its sequence number MUST be = checked; if its value is out of range defined by the last received sequence number and the = Detect Multiplexor, the packet MUST be = discarded.
    =0A=
    =0A=
     
    =0A=
    =0A=
    This may result in the a BFD session going down in the = situation when the transceiver "loses" the information about its last = transmitted sequence = number. A suitable use case is a multilink = interface (LAG, ML-PPP, etc.) with the links residing in = different line cards, and e BFD implemented in one of = these cards: if = this card fails, the BFD would could be re-started in one of = the remaining cards. Such a restart would not affect the = local session because the BFD machine would be = restarted with bfd.AuthSeqKnown =3D = 0, but keeping bfd.XmitAuthSeq consistent between different = line cards seems = problematic. (Implemeting BFD in some common card would resolve the = situation with the multilink interfaces but would raise similar issues when the = common card fails).
    =0A=
    =0A=
     
    =0A=
    =0A=
    Note that this problem would not occur for a = non-authenticated BFD session.
    =0A=
    =0A=
     
    =0A=
    =0A=
    IMHO this problem is real, and I do not see a simple solution for = it. 
    =0A=
    =0A=
    I would highly appreciate any feedback from the = draft authors and/or from the WG.
    =0A=
    =0A=
     
    =0A=
    =0A=
    Regards,
    =0A=
    =0A=
               =        Sasha
    =0A=
    =0A=
     



    On Jan 12, 2008, at 11:24 PM, Alexander Vainshtein wrote:
    David,
    I have probably poorly = presented the case=20 of an intermediate L2 device.
    What I have in mind is the = following=20 combination:
    1. A single L3 adjacency = monitored by BFD=20 that has been established across an intermediate L2 = device
    2. Different number of L2-bundled = links between=20 each of the L3 peers and the intermediate L2=20 device.

    I do not see how your proposed = solutions would help=20 to resolve the problem:

    1. Not sure why UDLR is relevant to = this scenario,=20 will look-up the appropriate RFC first=20
    2. LACP operates per L2-bundled link. = It would help=20 to detect a failure of such a link, but, IMHO, no more than=20 that



    1. L3 BFD between a L3 and L2 device = would not=20 affect the state of the L3 BFD session between the L3 = peers.






    Regards,

              &nbs= p;    =20 Sasha


    From: David Ward = [mailto:dward@cisco.com]
    Sent: Fri=20 1/11/2008 4:18 PM
    To: Alexander Vainshtein
    Cc: = David Ward;=20 Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor=20 Danilovich
    Subject: Re: Resetting the sequence number in an=20 authenticated BFD session

    Sasha -=20


    I think I already covered your points on centralization and = master=20 component link. WRT the issue that a L3 device is connected to an L2 = device=20 via a bundled interface and the far L3 device is single attached ... = BFD is=20 currently an L3 solution. You'd have to run LACP, UDLR or BFD at L3 to = the L2=20 device to cover this scenario.

    -DWard


    On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote:

    David, = Nitin and=20 all,
    Please see inline below = (blue italics)..Unfortunately it seems = that none of=20 the options explicitly proposed by David resolve the = issue.
     
    Regards,
              &nbs= p;     =20 Sasha

    From: David Ward [mailto:dward@cisco.com]
    Sent:=20 Thu 1/10/2008 11:51 PM
    To: Nitin Bahadur
    Cc: = David Ward;=20 Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor=20 Danilovich
    Subject: Re: Resetting the sequence number in = an=20 authenticated BFD session

    Solutions include (and are alluded to in the drafts):=20

    run BFD on bundled interfaces (any flavor) centrally [Sasha] This rasies the issue of the central = component=20 failover (as mentioned in my oriinal message).
     
    run BFD on all component links independently [Sasha] IMHO this is not a viable option. E.g., = consider a L3=20 1-hop situation where the bundled interfaces run between one of the = routers=20 and a L2 switch, while the L3 adjacency is unaware of bundling. This = is=20 easily achieved with LAG.
     
    run BFD on a master component link [Sasha] The=20 failure of the LC that carries the "master componet link" is the = original=20 scenario described in my original email, and the issue remains = unsloved=20 IMO.

    There are other variants as well.

    -DWard

    On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote:
    Alexander,
     
       I = agree that=20 keeping the sequence number=20 consistent between line cards is not practical. We need a way for = a system=20 to indicate that it wants to restart the sequence.
     
    Nitin
     
    From: Alexander Vainshtein = [mailto:Alexander.Vainsht= ein@ecitele.com] 
    Sent: Thursday, January 10, = 2008 12:42=20 PM
    To: David Ward; Dave Katz
    Cc: Ronen Sommer; BFD WG; = Igor=20 Danilovich
    Subject: Resetting the sequence number in an=20 authenticated BFD session
    Importance: High
    =  
    Hi=20 all,
    I have=20 a question related to the expected behavior of sequence numbers in an=20 aythenticated (MD5 or SHA1) BFD session.
     
    The=20 corresdponding sections of=20 draft-ietf-bfd-base-06 state that, once the packet has been = authenticated=20 by the receiver, its sequence number MUST be = checked;=20 if its value is out of range defined by the last received sequence number and the = Detect=20 Multiplexor, the packet MUST be = discarded.
     
    This=20 may result in the a BFD session going down in = the=20 situation when the transceiver "loses" the information about its = last=20 transmitted sequence number.=20 A suitable use case is a = multilink=20 interface (LAG, ML-PPP, etc.) with the links residing in=20 different line cards, and e BFD implemented in one of = these cards: if this=20 card fails, the BFD would could be re-started in one of = the=20 remaining cards. Such a restart would not affect the = local session=20 because the BFD machine would be restarted = with bfd.AuthSeqKnown =3D 0, but = keeping bfd.XmitAuthSeq consistent between = different line=20 cards seems = problematic.=20 (Implemeting BFD in some common card would resolve the situation = with the=20 multilink interfaces but would raise similar issues when the = common=20 card fails).
     
    Note=20 that this problem would not occur for a non-authenticated = BFD session.
     
    IMHO=20 this problem is real, and I do not see a simple solution = for=20 it. 
    I=20 would highly appreciate any feedback from the draft authors and/or = from=20 the WG.
     
    Regards,
               =       =20 Sasha
     


    =
    ------_=_NextPart_001_01C85608.1FF0EE3E-- From rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvS-0006vh-JN; Wed, 16 Jan 2008 11:15:38 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvQ-0006sK-A5 for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvP-0006qT-85; Wed, 16 Jan 2008 11:15:35 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFAvN-0001xy-40; Wed, 16 Jan 2008 11:15:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B5C2F328B6; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001SY-A9; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-generic-04.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Generic Application of BFD Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-generic-04.txt Pages : 19 Date : 2008-1-16 This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-generic-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-generic-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-TypeFrom rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvS-0006vh-JN; Wed, 16 Jan 2008 11:15:38 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvQ-0006sK-A5 for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvP-0006qT-85; Wed, 16 Jan 2008 11:15:35 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFAvN-0001xy-40; Wed, 16 Jan 2008 11:15:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B5C2F328B6; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001SY-A9; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-generic-04.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Generic Application of BFD Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-generic-04.txt Pages : 19 Date : 2008-1-16 This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-generic-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-generic-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-TypeFrom rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvS-0006vh-JN; Wed, 16 Jan 2008 11:15:38 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvQ-0006sK-A5 for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvP-0006qT-85; Wed, 16 Jan 2008 11:15:35 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFAvN-0001xy-40; Wed, 16 Jan 2008 11:15:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B5C2F328B6; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001SY-A9; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-generic-04.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Generic Application of BFD Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-generic-04.txt Pages : 19 Date : 2008-1-16 This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-generic-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-generic-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-generic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-generic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105629.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvY-0007AA-Vx; Wed, 16 Jan 2008 11:15:45 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvR-0006t6-QB for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvR-0006sf-3B; Wed, 16 Jan 2008 11:15:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFAvQ-0007eu-NK; Wed, 16 Jan 2008 11:15:36 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A21412AC5E; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001Se-BS; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-06.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-06.txt Pages : 7 Date : 2008-1-16 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-multihop-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-multihop-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers ex: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-generic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-generic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105629.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvY-0007AA-Vx; Wed, 16 Jan 2008 11:15:45 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvR-0006t6-QB for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvR-0006sf-3B; Wed, 16 Jan 2008 11:15:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFAvQ-0007eu-NK; Wed, 16 Jan 2008 11:15:36 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A21412AC5E; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001Se-BS; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-06.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-06.txt Pages : 7 Date : 2008-1-16 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-multihop-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-multihop-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers ex: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-generic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-generic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105629.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvY-0007AA-Vx; Wed, 16 Jan 2008 11:15:45 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvR-0006t6-QB for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvR-0006sf-3B; Wed, 16 Jan 2008 11:15:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFAvQ-0007eu-NK; Wed, 16 Jan 2008 11:15:36 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A21412AC5E; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001Se-BS; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-06.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-06.txt Pages : 7 Date : 2008-1-16 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-multihop-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-multihop-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105759.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvW-0006z9-9n; Wed, 16 Jan 2008 11:15:42 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvR-0006t7-QG for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvR-0006sg-3d; Wed, 16 Jan 2008 11:15:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFAvQ-0007et-NJ; Wed, 16 Jan 2008 11:15:37 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7E22E2AC3A; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001SS-8n; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-07.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-07.txt Pages : 8 Date : 2008-1-16 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or fthibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105759.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvW-0006z9-9n; Wed, 16 Jan 2008 11:15:42 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvR-0006t7-QG for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvR-0006sg-3d; Wed, 16 Jan 2008 11:15:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFAvQ-0007et-NJ; Wed, 16 Jan 2008 11:15:37 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7E22E2AC3A; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001SS-8n; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-07.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-07.txt Pages : 8 Date : 2008-1-16 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or fthibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105759.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jan 16 11:15:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvW-0006z9-9n; Wed, 16 Jan 2008 11:15:42 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFAvR-0006t7-QG for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:15:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAvR-0006sg-3d; Wed, 16 Jan 2008 11:15:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFAvQ-0007et-NJ; Wed, 16 Jan 2008 11:15:37 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7E22E2AC3A; Wed, 16 Jan 2008 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFAus-0001SS-8n; Wed, 16 Jan 2008 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 11:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-07.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-07.txt Pages : 8 Date : 2008-1-16 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105507.I-D@ietf.org> --OtherAccess-- --NextPart-- p://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105507.I-D@ietf.org> --OtherAccess-- --NextPart-- p://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16105507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16105507.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jan 16 12:15:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBrV-0007gh-9B; Wed, 16 Jan 2008 12:15:37 -0500 Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JFBrR-0007by-Bl for rtg-bfd-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 12:15:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBrR-0007bq-0U; Wed, 16 Jan 2008 12:15:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFBrQ-0002gR-Kj; Wed, 16 Jan 2008 12:15:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 86CA62AC46; Wed, 16 Jan 2008 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFBqw-0004UL-9A; Wed, 16 Jan 2008 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Jan 2008 12:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-base-07.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Bidirectional Forwarding Detection Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-base-07.txt Pages : 48 Date : 2008-1-16 This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-base-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-base-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-16110402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-base-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-base-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-16110402.I-D@ietf.org> --OtherAccess-- --NextPart--