From rtg-bfd-bounces@ietf.org Thu Dec 20 14:19:43 2007
Return-path: <rtg-bfd-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5Qvh-00075T-Dn; Thu, 20 Dec 2007 14:19:37 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43)
	id 1J5Qvg-0006z8-6E for rtg-bfd-confirm+ok@megatron.ietf.org;
	Thu, 20 Dec 2007 14:19:36 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43)
	id 1J5Qvf-0006yh-SX
	for rtg-bfd@ietf.org; Thu, 20 Dec 2007 14:19:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QlF-0004XO-Ka
	for rtg-bfd@ietf.org; Thu, 20 Dec 2007 14:08:49 -0500
Received: from rv-out-0910.google.com ([209.85.198.185])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5QlF-0005KS-6y
	for rtg-bfd@ietf.org; Thu, 20 Dec 2007 14:08:49 -0500
Received: by rv-out-0910.google.com with SMTP id c24so2647386rvf.47
	for <rtg-bfd@ietf.org>; Thu, 20 Dec 2007 11:08:47 -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=XZ9mSBu26sSEr6dZvs4tHCvvnnZ2Qgv5BT9Y70N44A8=;
	b=gSh/YzbdRPdQuunqpqb2YgXNMFW0OM/aYJja1GtMLpVHGUGfZv7JeL0YXQc8ODMNSfrqWMI5dAc4IV9P5JYu0iAYKTf3TOgMMIMkr++/7eagYb/HdmOP0x6GagH5t8A0uL3qoRUmIL1HjxdJNoFsK7jIKe3FsK64kWBltIi7ciw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:mime-version:content-type;
	b=XXpYRfol4LQU6QOEr5+cLLURaxS+kDlXSSoa9QwJZM3sinzcM65PoFKxAnp7izKnSGmmggPobCjrD4B2McRobHAss1S1Y+y7deAzTHVUO4NmxikmPN+cvgRlRcB4633855nSZ01DfI9bzxpfnaMDRYT88uIegfT+sovM+Bjhyrg=
Received: by 10.141.36.10 with SMTP id o10mr212489rvj.176.1198177727035;
	Thu, 20 Dec 2007 11:08:47 -0800 (PST)
Received: by 10.140.249.19 with HTTP; Thu, 20 Dec 2007 11:08:47 -0800 (PST)
Message-ID: <e70833f50712201108v284939bqed11a315a0fbda76@mail.gmail.com>
Date: Thu, 20 Dec 2007 14:08:47 -0500
From: "Jagrati Shringi" <shringi@gmail.com>
To: rtg-bfd@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_13153_11468928.1198177727028"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
X-TMDA-Confirmed: Thu, 20 Dec 2007 14:19:35 -0500
Subject: BFD Admin-down
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Errors-To: rtg-bfd-bounces@ietf.org

------=_Part_13153_11468928.1198177727028
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have a question regarding BFD state - Administratively-down. The base
draft recommend that we send a packet with
Local state: Down  and Appropriate diag in this case and then stop
transmitting control packets. This way we will send very few or may be one
packet with state down and diagnostic:7 .

My question is, this seem to be the only case in BFD where we will not be
able to maintain correct diagnostic on remote end, in case the packet
carrying this information is dropped. If the peer does not receive this
packet, it will move to down-state with Diag :Control Detection Time
Expired, instead of Neighbor Signaled Session Down.

Please let me know what is the recommended approach in this case, so that we
maintain right state/diag code on peer, even if we loose some packets.

Thanks in advance for your help.

Jagrati Shringi,
Senior Software engineer,
ECI Telecom.

------=_Part_13153_11468928.1198177727028
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


<br>I have a question regarding BFD state - Administratively-down. The base draft recommend that we send a packet with 
<br>Local state: Down &nbsp;and Appropriate diag in this case and then stop
transmitting control packets. This way we will send very few or may be
one packet with state down and diagnostic:7 .
<br>&nbsp;
<br>My question is, this seem to be the only case in BFD where we will
not be able to maintain correct diagnostic on remote end, in case the
packet carrying this information is dropped. If the peer does not
receive this packet, it will move to down-state with Diag :Control
Detection Time Expired, instead of Neighbor Signaled Session Down.
<br>&nbsp;
<br>Please let me know what is the recommended approach in this case,
so that we maintain right state/diag code on peer, even if we loose
some packets.
<br>&nbsp;
<br>Thanks in advance for your help. 
<br>&nbsp;
<br>Jagrati Shringi,
<br>Senior Software engineer,
<br>ECI Telecom. 






------=_Part_13153_11468928.1198177727028--






From rtg-bfd-bounces@ietf.org Thu Dec 20 16:52:08 2007
Return-path: <rtg-bfd-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5TJH-0008Uv-Dy; Thu, 20 Dec 2007 16:52:07 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43)
	id 1J5TJG-0008OL-MJ for rtg-bfd-confirm+ok@megatron.ietf.org;
	Thu, 20 Dec 2007 16:52:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TJG-0008Hj-5K
	for rtg-bfd@ietf.org; Thu, 20 Dec 2007 16:52:06 -0500
Received: from exprod7og111.obsmtp.com ([64.18.2.175] helo=psmtp.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5TJF-0004Ca-Ib
	for rtg-bfd@ietf.org; Thu, 20 Dec 2007 16:52:06 -0500
Received: from source ([66.129.224.36]) by exprod7ob111.postini.com
	([64.18.6.12]) with SMTP; Thu, 20 Dec 2007 13:51:58 PST
Received: from emailcorp1.jnpr.net ([66.129.254.11]) by gamma.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 13:52:00 -0800
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp1.jnpr.net
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 20 Dec 2007 13:51:58 -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_01C84351.979CFDCA"
Date: Thu, 20 Dec 2007 13:45:09 -0800
Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E8B2296@emailcorp3.jnpr.net>
In-Reply-To: <e70833f50712201108v284939bqed11a315a0fbda76@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BFD Admin-down
Thread-Index: AchDPUjPUq3yzcPwRjClq5iNkuNHnwAEwF5w
References: <e70833f50712201108v284939bqed11a315a0fbda76@mail.gmail.com>
From: "Nitin Bahadur" <nitinb@juniper.net>
To: "Jagrati Shringi" <shringi@gmail.com>,
	<rtg-bfd@ietf.org>
X-OriginalArrivalTime: 20 Dec 2007 21:51:58.0672 (UTC)
	FILETIME=[8B7DDD00:01C84352]
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc: 
Subject: RE: BFD Admin-down
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Errors-To: rtg-bfd-bounces@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C84351.979CFDCA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It would be nice if one would transmit packets for at least 1
detection-time period before ceasing=20

packet transmission. One detection-time worth of packets would ensure
that the peer either receives

a packet (with correct diag) within that period or the peer times out
(as it would have done normally).

=20

Nitin

=20

My question is, this seem to be the only case in BFD where we will not
be able to maintain correct diagnostic on remote end, in case the packet
carrying this information is dropped. If the peer does not receive this
packet, it will move to down-state with Diag :Control Detection Time
Expired, instead of Neighbor Signaled Session Down.=20
 =20
Please let me know what is the recommended approach in this case, so
that we maintain right state/diag code on peer, even if we loose some
packets.=20




------_=_NextPart_001_01C84351.979CFDCA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It would be nice if one would =
transmit packets
for at least 1 detection-time period before ceasing =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>packet transmission. One =
detection-time
worth of packets would ensure that the peer either =
receives<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>a packet (with correct diag) within =
that
period or the peer times out (as it would have done =
normally).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Nitin<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>My question is, this <st1:PersonName =
w:st=3D"on">se</st1:PersonName>em to
be the only ca<st1:PersonName w:st=3D"on">se</st1:PersonName> in BFD =
where we
will not be able to maintain correct diagnostic on remote end, in =
ca<st1:PersonName
w:st=3D"on">se</st1:PersonName> the packet carrying this information is =
dropped.
If the peer does not receive this packet, it will move to down-state =
with Diag
:Control Detection Time Expired, instead of Neighbor Signaled Session =
Down. <br>
&nbsp; <br>
Plea<st1:PersonName w:st=3D"on">se</st1:PersonName> let me know what is =
the
recommended approach in this ca<st1:PersonName =
w:st=3D"on">se</st1:PersonName>,
so that we maintain right state/diag code on peer, even if we =
loo<st1:PersonName
w:st=3D"on">se</st1:PersonName> some packets. <br>
<br>
<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C84351.979CFDCA--





From rtg-bfd-bounces@ietf.org Mon Dec 24 10:55:32 2007
Return-path: <rtg-bfd-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6peG-0003HI-UJ; Mon, 24 Dec 2007 10:55:24 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43)
	id 1J6peE-0003GU-Tv for rtg-bfd-confirm+ok@megatron.ietf.org;
	Mon, 24 Dec 2007 10:55:22 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J6peE-0003DV-Hc
	for rtg-bfd@ietf.org; Mon, 24 Dec 2007 10:55:22 -0500
Received: from eci-iron1.ecitele.com ([147.234.242.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6peE-00032x-3E
	for rtg-bfd@ietf.org; Mon, 24 Dec 2007 10:55:22 -0500
Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44])
	by eci-iron1.ecitele.com with ESMTP; 24 Dec 2007 18:08:28 +0200
Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by
	ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 24 Dec 2007 17:55:20 +0200
Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by
	ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id
	8.1.240.5; Mon, 24 Dec 2007 17:55:19 +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_01C84645.623E426E"
Date: Mon, 24 Dec 2007 17:55:19 +0200
Message-ID: <64122293A6365B4A9794DC5636F9ACFD0252E22C@ilptex01.ecitele.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What is the status of the WG documents?
Thread-Index: AchGRWJTSg9Tp6rsQYSoOWe3rMC00w==
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: <dward@cisco.com>,
	<jhaas@prfc.org>
X-OriginalArrivalTime: 24 Dec 2007 15:55:20.0452 (UTC)
	FILETIME=[62CF9C40:01C84645]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: rtg-bfd@ietf.org, Alik Shimelmits <Alik.Shimelmits@ecitele.com>
Subject: What is the status of the WG documents?
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>,
	<mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Errors-To: rtg-bfd-bounces@ietf.org

------_=_NextPart_001_01C84645.623E426E
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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_01C84645.623E426E
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial size=3D2>Dave, =
Jeffrey and=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial size=3D2>I have =
missed the=20
Vancouver IETF meeting, and I would like to know what happens to the WG=20
drafts.</FONT></SPAN></DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial size=3D2>At the =
Prague=20
meeting they have been declared as ready for the WG LC, but, AFAIK, it =
has never=20
been declared.</FONT></SPAN></DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial size=3D2>And =
most of the=20
drafts have now expired.</FONT></SPAN></DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial size=3D2>Any =
info will be=20
highly appreciated.</FONT></SPAN></DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D781185115-24122007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
Sasha Vainshtein</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C84645.623E426E--