From rtg-bfd-bounces@ietf.org Fri Mar 10 19:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHrXJ-0000Ul-OL; Fri, 10 Mar 2006 19:00:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHrXI-0000Ug-Px for rtg-bfd@ietf.org; Fri, 10 Mar 2006 19:00:44 -0500 Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHrXI-00059O-92 for rtg-bfd@ietf.org; Fri, 10 Mar 2006 19:00:44 -0500 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 11 Mar 2006 00:00:43 +0000 X-SBRS: None X-IronPort-AV: i="4.02,182,1139184000"; d="scan'208,217"; a="46954089:sNHT155056980" Received: from ussj1wms2.tellabs-west.tellabsinc.net ([172.25.6.30]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Mar 2006 18:00:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6449E.D6D77468" Date: Fri, 10 Mar 2006 16:00:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD for Multi Topology IS-IS Thread-Index: AcZEntb8AEcZdgL+TsiiR80Z7WAHmA== From: "Pudiyapura, Ajeer" To: X-OriginalArrivalTime: 11 Mar 2006 00:00:43.0517 (UTC) FILETIME=[D75A2AD0:01C6449E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Subject: BFD for Multi Topology IS-IS 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_01C6449E.D6D77468 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" >From the Single-Hop draft (BFD for IPv4 and IPv6 (Single Hop) draft-ietf-bfd-v4v6-1hop-04.txt) section 7.3: =20 Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in the routing protocol to signal the lack of connectivity for the data protocol (IPv4 or IPv6) over which BFD is running. If only one data protocol is being advertised in the routing protocol Hello, or if multiple protocols are being advertised but the protocols must share a common topology, a Hello protocol timeout SHOULD be emulated for the associated OSPF neighbors and/or IS-IS adjacencies. =20 If multiple data protocols are advertised in the routing protocol Hello, and the routing protocol supports different topologies for each data protocol, the failing data protocol SHOULD no longer be advertised in Hello packets in order to signal a lack of connectivity for that protocol. =20 Talking from an MT-IS-IS context where both IPv4-unicast and IPv6-unicast topologies are enabled (see second paragraph above) on the link: =20 1=2E Why do we require IS-IS to convey the lack of connectivity to the neighbor? Doesn't BFD on the neighboring router detect it as well (much faster)? 2=2E Which field in the IIH is implied here? NLPID or MTID TLV? 3=2E Why do we need to modify these fields, which advertise the configuration and capabilities supported on the link, when a neighbor state changes? 4=2E Doesn't changing these fields in our Hello packet affect all neighbors on the shared link? 5=2E Isn't it sufficient to just emulate receiving a Hello from the neighbor without the corresponding NLPID and MTIDs, which would cause only the failed protocol to re-route around the neighbor, without affecting anything else? =20 Thanks -Ajeer Pudiyapura =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C6449E.D6D77468 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

From the Single-Hop draft (BFD for IPv4 and IPv6 (Single Hop) draft-ietf-bfd-v4v6-1hop-04.txt) section 7.3:=

 

   Therefore, when a BFD session transitions f= rom Up to Down, action

   SHOULD be taken in the routing protocol to signal the lack of

   connectivity for the data protocol (IPv4 or IPv6) over which BFD is

   running.  If only one data protocol is= being advertised in the

   routing protocol Hello, or if multiple protocols are being advertised

   but the protocols must share a common topol= ogy, a Hello protocol

   timeout SHOULD be emulated for the associat= ed OSPF neighbors and/or

   IS-IS adjacencies.=

 

   If multiple data protocols are advertised in the routing protocol

   Hello, and the routing protocol supports different topologies for

   each data protocol, the failing data protoc= ol SHOULD no longer be

   advertised in Hello packets in order to sig= nal a lack of connectivity

   for that protocol.=

 

Talking from an MT-IS-IS context where both IPv4-unicast= and IPv6-unicast topologies are enabled (see second paragraph above) on the lin= k:

 

1. Why do we require IS-IS to convey the lack of connectivity to the neighbor? Doesn’t BFD on the neighboring router detect it as well (much faster)?

2. Which field in the IIH is implied here? NLPID or MTID= TLV?

3. Why do we need to modify these fields, which advertise the configuration and capabilities supported on the link, when a neighbor s= tate changes?

4. Doesn’t changing these fields in our Hello pack= et affect all neighbors on the shared link?

5. Isn’t it sufficient to just emulate receiving a Hello from the neighbor without the corresponding NLPID and MTIDs, which wo= uld cause only the failed protocol to re-route around the neighbor, without aff= ecting anything else?

 

Thanks

-Ajeer Pudiyapura

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C6449E.D6D77468-- From rtg-bfd-bounces@ietf.org Tue Mar 21 19:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLr5U-0001NP-Cz; Tue, 21 Mar 2006 19:20:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLr5T-0001NK-Cj for rtg-bfd@ietf.org; Tue, 21 Mar 2006 19:20:31 -0500 Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLr5S-0003kR-2x for rtg-bfd@ietf.org; Tue, 21 Mar 2006 19:20:31 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k2M0KR5k015692; Tue, 21 Mar 2006 18:20:27 -0600 Received: from SatyamXP (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id k2M0Knvs002940; Tue, 21 Mar 2006 16:20:50 -0800 (PST) Message-Id: <200603220020.k2M0Knvs002940@mvrelay.mv.usa.alcatel.com> From: "Satyam Sinha" To: Date: Tue, 21 Mar 2006 16:20:26 -0800 Organization: Alcatel MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZNRmrGEcyckDCrQH+tRipQk/K4GA== X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: BFD Sessions: Graceful Shutdown X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: satyam.sinha@alcatel.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org Hi, Presently, we do not have any way to gracefully shutdown a BFD session. By looking at the drafts, I could not find a way by which we could de-couple a BFD session from a registered protocol. If a user decides to decouple the BFD session from a protocol registered to use the BFD session, tearing down the BFD session will always causes the protocol to take the adjacency down. For some administrative reason, if we do decide to decouple the session, we should have a way to do it. One solution would be that the requestor could probably send a BFD message with a "Diag Code - Graceful Shutdown" or somesuch alongwith the 'P' bit set. The requestor on receiving the same diag code and the 'F' bit set could tear down the session gracefully. Regards, -Satyam. ---------------- IP Division Alcatel USA From rtg-bfd-bounces@ietf.org Tue Mar 21 21:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsen-00060n-13; Tue, 21 Mar 2006 21:01:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsem-00060i-2j for rtg-bfd@ietf.org; Tue, 21 Mar 2006 21:01:04 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLsek-0007K5-SQ for rtg-bfd@ietf.org; Tue, 21 Mar 2006 21:01:04 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2006 18:01:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,116,1141632000"; d="scan'208"; a="24148502:sNHT22255384" Received: from cisco.com (che-vpn-cluster-1-8.cisco.com [10.86.240.8]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2M20vVU021432; Tue, 21 Mar 2006 21:00:58 -0500 (EST) Message-ID: <4420AFD8.1010908@cisco.com> Date: Tue, 21 Mar 2006 21:00:56 -0500 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: satyam.sinha@alcatel.com References: <200603220020.k2M0Knvs002940@mvrelay.mv.usa.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rtg-bfd@ietf.org Subject: Re: BFD Sessions: Graceful Shutdown 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 I think the admindown state is also for gracefully shutting down a BFD session (see 6.7.17. Administrative Control). So the procedure should be something like this 1- Requestor sets state to admindown, local diag to the appropriate value and sets P bit 2- From 6.7.6 BFD at the other end goes down: If received state is AdminDown If bfd.SessionState is not Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down 3- On receiving F bit the requestor can remove the session if needed. I think the part which isn't mentioned in the draft is that when a session goes down because the remote is admindown, then the protocol adjacency should not go down. Regards, Reshad. Satyam Sinha wrote: >Hi, > >Presently, we do not have any way to gracefully shutdown a BFD session. By looking at the drafts, I >could not find a way by which we could de-couple a BFD session from a registered protocol. > >If a user decides to decouple the BFD session from a protocol registered to use the BFD session, >tearing down the BFD session will always causes the protocol to take the adjacency down. For some >administrative reason, if we do decide to decouple the session, we should have a way to do it. > >One solution would be that the requestor could probably send a BFD message with a "Diag Code - >Graceful Shutdown" or somesuch alongwith the 'P' bit set. The requestor on receiving the same diag >code and the 'F' bit set could tear down the session gracefully. > >Regards, > >-Satyam. >---------------- >IP Division >Alcatel USA > > From rtg-bfd-bounces@ietf.org Wed Mar 22 12:54:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7XY-0007oF-OR; Wed, 22 Mar 2006 12:54:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7XW-0007h2-O2 for rtg-bfd@ietf.org; Wed, 22 Mar 2006 12:54:34 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7XV-0001ZH-EP for rtg-bfd@ietf.org; Wed, 22 Mar 2006 12:54:34 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 22 Mar 2006 09:54:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2MHsWGv008234; Wed, 22 Mar 2006 09:54:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:54:32 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:54:31 -0800 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 22 Mar 2006 11:54:30 -0600 From: David Ward To: Reshad Rahman , Message-ID: Thread-Topic: BFD Sessions: Graceful Shutdown Thread-Index: AcZN2asS6WSrq7nMEdqDTwAKlcR7kg== In-Reply-To: <4420AFD8.1010908@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2006 17:54:31.0758 (UTC) FILETIME=[AC1ECEE0:01C64DD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: rtg-bfd@ietf.org Subject: Re: BFD Sessions: Graceful Shutdown 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 discussed in the state machine and subsequent textual description. -DWard On 3/21/06 8:00 PM, "Reshad Rahman" wrote: > I think the admindown state is also for gracefully shutting down a BFD > session (see 6.7.17. Administrative Control). So the procedure should be > something like this > 1- Requestor sets state to admindown, local diag to the appropriate > value and sets P bit > 2- From 6.7.6 BFD at the other end goes down: > If received state is AdminDown > If bfd.SessionState is not Down > Set bfd.LocalDiag to 3 (Neighbor signaled session down) > Set bfd.SessionState to Down > 3- On receiving F bit the requestor can remove the session if needed. > > I think the part which isn't mentioned in the draft is that when a > session goes down because the remote is admindown, then the protocol > adjacency should not go down. > > Regards, > Reshad. > > Satyam Sinha wrote: > >> Hi, >> >> Presently, we do not have any way to gracefully shutdown a BFD session. By >> looking at the drafts, I >> could not find a way by which we could de-couple a BFD session from a >> registered protocol. >> >> If a user decides to decouple the BFD session from a protocol registered to >> use the BFD session, >> tearing down the BFD session will always causes the protocol to take the >> adjacency down. For some >> administrative reason, if we do decide to decouple the session, we should >> have a way to do it. >> >> One solution would be that the requestor could probably send a BFD message >> with a "Diag Code - >> Graceful Shutdown" or somesuch alongwith the 'P' bit set. The requestor on >> receiving the same diag >> code and the 'F' bit set could tear down the session gracefully. >> >> Regards, >> >> -Satyam. >> ---------------- >> IP Division >> Alcatel USA >> >> From rtg-bfd-bounces@ietf.org Fri Mar 31 06:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPHUP-0001GF-Lk; Fri, 31 Mar 2006 06:08:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPHUN-00014C-HJ for rtg-bfd@ietf.org; Fri, 31 Mar 2006 06:08:23 -0500 Received: from bay21-f7.bay21.hotmail.com ([65.54.233.96] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPHUM-0003NG-8A for rtg-bfd@ietf.org; Fri, 31 Mar 2006 06:08:23 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 31 Mar 2006 03:08:21 -0800 Message-ID: Received: from 64.215.168.114 by by21fd.bay21.hotmail.msn.com with HTTP; Fri, 31 Mar 2006 11:08:21 GMT X-Originating-IP: [59.144.1.153] X-Originating-Email: [mithra_vasudevan@hotmail.com] X-Sender: mithra_vasudevan@hotmail.com From: "Mithra Vasudevan" To: rtg-bfd@ietf.org Bcc: Date: Fri, 31 Mar 2006 16:38:21 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 31 Mar 2006 11:08:21.0349 (UTC) FILETIME=[6BF14150:01C654B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: update for draft-ietf-bfd-mpls-02.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 Hello When would an update for draft-ietf-bfd-mpls-02.txt be available? Best Regards Mithra _________________________________________________________________ NRIs: Still paying for money transfers? Now send Money2India for FREE! http://ads.mediaturf.net/event.ng/Type=click&FlightID=20273&AdID=65990&TargetID=11172&Targets=11172&Values=202,414,1093,1264,3122&Redirect=http:%2F%2Fwww.icicinri.net%2Fmoney2india%2F%3Fm2i%3DBAC-MSN%26att%3DMSNTLM2I70CHAR%26rfr%3DMSNTLM2I70CHAR From rtg-bfd-bounces@ietf.org Fri Mar 31 18:09:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSkd-0001xP-A3; Fri, 31 Mar 2006 18:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSkb-0001xK-WE for rtg-bfd@ietf.org; Fri, 31 Mar 2006 18:09:54 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPSka-0003CN-O3 for rtg-bfd@ietf.org; Fri, 31 Mar 2006 18:09:53 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 31 Mar 2006 15:09:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,152,1141632000"; d="scan'208"; a="537102626:sNHT20801196" Received: from sapphire.juniper.net ([172.17.28.108]) by alpha.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 15:09:51 -0800 Date: Fri, 31 Mar 2006 15:09:51 -0800 (PST) From: Rahul Aggarwal To: Mithra Vasudevan In-Reply-To: Message-ID: <20060331150908.R30356@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 31 Mar 2006 23:09:52.0005 (UTC) FILETIME=[372F2350:01C65518] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rtg-bfd@ietf.org Subject: Re: update for draft-ietf-bfd-mpls-02.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 Hi Mithra, On Fri, 31 Mar 2006, Mithra Vasudevan wrote: > Hello > > When would an update for draft-ietf-bfd-mpls-02.txt be available? > It will be posted in the next couple of weeks. rahul > Best Regards > Mithra > > _________________________________________________________________ > NRIs: Still paying for money transfers? Now send Money2India for FREE! > http://ads.mediaturf.net/event.ng/Type=click&FlightID=20273&AdID=65990&TargetID=11172&Targets=11172&Values=202,414,1093,1264,3122&Redirect=http:%2F%2Fwww.icicinri.net%2Fmoney2india%2F%3Fm2i%3DBAC-MSN%26att%3DMSNTLM2I70CHAR%26rfr%3DMSNTLM2I70CHAR > >