From sambath_kumar_b@yahoo.com  Thu Apr 15 13:58:10 2010
Return-Path: <sambath_kumar_b@yahoo.com>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8B73A6A63 for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 13:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.835
X-Spam-Level: ***
X-Spam-Status: No, score=3.835 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUNJwqryfp1E for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 13:58:09 -0700 (PDT)
Received: from n3-vm0.bullet.mail.gq1.yahoo.com (n3-vm0.bullet.mail.gq1.yahoo.com [67.195.23.156]) by core3.amsl.com (Postfix) with SMTP id 690FD3A69F3 for <rtg-bfd@ietf.org>; Thu, 15 Apr 2010 13:58:06 -0700 (PDT)
Received: from [67.195.9.82] by n3.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2010 20:57:57 -0000
Received: from [98.137.27.213] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2010 20:57:57 -0000
Received: from [127.0.0.1] by omp123.mail.gq1.yahoo.com with NNFMP; 15 Apr 2010 20:57:57 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 438936.88734.bm@omp123.mail.gq1.yahoo.com
Received: (qmail 33766 invoked by uid 60001); 15 Apr 2010 20:57:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271365077; bh=soexar60bK5bVTO7mJBzLFgWQVJScmyPYCuKSq1aJyU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=h8i5c7V8yv+p6XY5f7yGyE9pBhID1TYdKXJRUUll1hhdAAzKF6/i4nQdviAs9TGGZdw1Kx2EJayJVtWFi7aCFVRGd+BJTimLvO14U25jNo15dpqynZ8AxeYDYwRi2GN8ZFm3P2jrgWoynVexnObUA1R3qrFc56i+/dI//Zyhrv8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=wCdboEiHQ4O46RKCII9R4f9bdVdr9IPqR5gzqPXir2qu9diBKUUREPAav7RuqqgZt/vRc+8xXkrn8oPqepBf9WY52WJzdoLFI47iaKw1pUPpoYNdTnIJi6lNibIUkD+iSSWWvv7kwQZ2jzVYJ3sa/EHv8leV0vR9zfftgL2cV3I=;
Message-ID: <364645.31664.qm@web180310.mail.gq1.yahoo.com>
X-YMail-OSG: 7Za6mT4VM1m2ToNU_3UtYGfNYqiBI77kleWyPRnMX150mmY 3nl.hVMc3NsSsT1FvZmPp0Obac_zhZF0u2nB5k70JucN6JxPC7vBfYE89Wh9 GkXGx9uIaXoO0NbXJOmN0cWgSYDkkPk8OgjZtf2Gi0tsS9GJcwWDB.YMrHbA okwOBdORxtiLDZlCVgIF8nVgrMYrbOP7ICkWLQhmNOi7TLWrZBucqyASfyyb U.5xcO_VaqvOfJ3ZuU1UTy3evSEVaAikJARVef2p2FWDpCVytkr2w__MIH9r qrfwTAE73HQVn8ZF86BvFkJtg_BFVSMIIqJCVJxweMY9PctKZqyE0
Received: from [65.223.109.250] by web180310.mail.gq1.yahoo.com via HTTP; Thu, 15 Apr 2010 13:57:57 PDT
X-Mailer: YahooMailRC/348.3 YahooMailWebService/0.8.100.260964
Date: Thu, 15 Apr 2010 13:57:57 -0700 (PDT)
From: sambath kumar <sambath_kumar_b@yahoo.com>
Subject: Connection collision in BFD
To: rtg-bfd@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1169548597-1271365077=:31664"
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 20:58:10 -0000

--0-1169548597-1271365077=:31664
Content-Type: text/plain; charset=us-ascii

Hi,

   How does connection collision gets resolved in BFD? What if 2 systems are
trying to create BFD sessions to each other at the same time. Is there is a possibility 
that we might land up with 2 sessions?

 Regards,
Sambath

--0-1169548597-1271365077=:31664
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt">Hi,<br><br>&nbsp;&nbsp; How does connection collision gets resolved in BFD? What if 2 systems are<br>trying to create BFD sessions to each other at the same time. Is there is a possibility <br>that we might land up with 2 sessions?<br><div>&nbsp;</div>Regards,<br>Sambath<br></div></body></html>
--0-1169548597-1271365077=:31664--


From satyamsinha@live.com  Thu Apr 15 14:17:36 2010
Return-Path: <satyamsinha@live.com>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868623A6A4A for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 14:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.38
X-Spam-Level: 
X-Spam-Status: No, score=-96.38 tagged_above=-999 required=5 tests=[BAYES_95=3, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPA8GVm6DrqQ for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 14:17:35 -0700 (PDT)
Received: from bay0-omc3-s3.bay0.hotmail.com (bay0-omc3-s3.bay0.hotmail.com [65.54.190.141]) by core3.amsl.com (Postfix) with ESMTP id 5A9033A6A6D for <rtg-bfd@ietf.org>; Thu, 15 Apr 2010 14:16:47 -0700 (PDT)
Received: from BAY117-W32 ([65.54.190.189]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:16:41 -0700
Message-ID: <BAY117-W32354A6F54F3E01546A564CD0F0@phx.gbl>
Content-Type: multipart/alternative; boundary="_42a41c7e-7347-4a56-876e-de0aa061d53e_"
X-Originating-IP: [64.47.51.158]
From: Satyam Sinha <satyamsinha@live.com>
To: <sambath_kumar_b@yahoo.com>, <rtg-bfd@ietf.org>
Subject: RE: Connection collision in BFD
Date: Thu, 15 Apr 2010 14:16:40 -0700
Importance: Normal
In-Reply-To: <364645.31664.qm@web180310.mail.gq1.yahoo.com>
References: <364645.31664.qm@web180310.mail.gq1.yahoo.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Apr 2010 21:16:41.0392 (UTC) FILETIME=[F160D300:01CADCE0]
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 21:17:36 -0000

--_42a41c7e-7347-4a56-876e-de0aa061d53e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Sambath=2C

A BFD session is identified by remote-discr/local-discr pair so its possibl=
e that you could have criss-cross on multiple BFD sessions between two syst=
ems (and thats acceptable). However=2C when you have only one BFD session b=
etween the two systems=2C you will get only one session as both ends have a=
llocated only one discriminator each.=20

Can you explain the interaction which could possibly get two sessions ?

Regards=2C

Satyam



Date: Thu=2C 15 Apr 2010 13:57:57 -0700
From: sambath_kumar_b@yahoo.com
Subject: Connection collision in BFD
To: rtg-bfd@ietf.org



Hi=2C

   How does connection collision gets resolved in BFD? What if 2 systems ar=
e
trying to create BFD sessions to each other at the same time. Is there is a=
 possibility=20
that we might land up with 2 sessions?
 Regards=2C
Sambath
 		 	   		 =20
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your =
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=3DPID28326::T:WLMTAGL:O=
N:WL:en-US:WM_HMP:042010_2=

--_42a41c7e-7347-4a56-876e-de0aa061d53e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
--></style>
</head>
<body class=3D'hmmessage'>
Hi Sambath=2C<br><br>A BFD session is identified by remote-discr/local-disc=
r pair so its possible that you could have criss-cross on multiple BFD sess=
ions between two systems (and thats acceptable). However=2C when you have o=
nly one BFD session between the two systems=2C you will get only one sessio=
n as both ends have allocated only one discriminator each. <br><br>Can you =
explain the interaction which could possibly get two sessions ?<br><br>Rega=
rds=2C<br><br>Satyam<br><br><br><br><hr id=3D"stopSpelling">Date: Thu=2C 15=
 Apr 2010 13:57:57 -0700<br>From: sambath_kumar_b@yahoo.com<br>Subject: Con=
nection collision in BFD<br>To: rtg-bfd@ietf.org<br><br>

<style>
.ExternalClass DIV
{=3B}
</style><div style=3D"font-family: times new roman=2Cnew york=2Ctimes=2Cser=
if=3B font-size: 12pt=3B">Hi=2C<br><br>&nbsp=3B&nbsp=3B How does connection=
 collision gets resolved in BFD? What if 2 systems are<br>trying to create =
BFD sessions to each other at the same time. Is there is a possibility <br>=
that we might land up with 2 sessions?<br><div>&nbsp=3B</div>Regards=2C<br>=
Sambath<br></div> 		 	   		  <br /><hr />Hotmail is redefining busy with to=
ols for the New Busy. Get more from your inbox. <a href=3D'http://www.windo=
wslive.com/campaign/thenewbusy?ocid=3DPID28326::T:WLMTAGL:ON:WL:en-US:WM_HM=
P:042010_2' target=3D'_new'>See how.</a></body>
</html>=

--_42a41c7e-7347-4a56-876e-de0aa061d53e_--

From davari@broadcom.com  Thu Apr 15 14:19:41 2010
Return-Path: <davari@broadcom.com>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A6D3A6A87 for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 14:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.192
X-Spam-Level: 
X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=-1.194, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+sTImH3WE-J for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 14:19:39 -0700 (PDT)
Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id E43663A6A92 for <rtg-bfd@ietf.org>; Thu, 15 Apr 2010 14:18:44 -0700 (PDT)
Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 15 Apr 2010 14:18:22 -0700
X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201
Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 15 Apr 2010 14:18:22 -0700
From: "Shahram Davari" <davari@broadcom.com>
To: "sambath kumar" <sambath_kumar_b@yahoo.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Date: Thu, 15 Apr 2010 14:18:21 -0700
Subject: RE: Connection collision in BFD
Thread-Topic: Connection collision in BFD
Thread-Index: Acrc3nTVpOgnEyVoRKizA4UTUzLxswAAlUwQ
Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F03BA957@SJEXCHCCR02.corp.ad.broadcom.com>
References: <364645.31664.qm@web180310.mail.gq1.yahoo.com>
In-Reply-To: <364645.31664.qm@web180310.mail.gq1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 67D95D1431G92176828-01-01
Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BA957SJEXCHCCR02co_
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 21:19:41 -0000

--_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BA957SJEXCHCCR02co_
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

This is the normal operation when both systems are in Active mode. It is th=
e responsibility of each system to bind these two stream to each other.

Regards,
Shahram

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf =
Of sambath kumar
Sent: Thursday, April 15, 2010 1:58 PM
To: rtg-bfd@ietf.org
Subject: Connection collision in BFD

Hi,

   How does connection collision gets resolved in BFD? What if 2 systems ar=
e
trying to create BFD sessions to each other at the same time. Is there is a=
 possibility
that we might land up with 2 sessions?

Regards,
Sambath

--_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BA957SJEXCHCCR02co_
Content-Type: text/html;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Hi,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>This is the normal operation when both systems are in Active
mode. It is the responsibility of each system to bind these two stream to e=
ach
other.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Regards,<br>
Shahram<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] <b>On Behalf Of =
</b>sambath
kumar<br>
<b>Sent:</b> Thursday, April 15, 2010 1:58 PM<br>
<b>To:</b> rtg-bfd@ietf.org<br>
<b>Subject:</b> Connection collision in BFD<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>Hi,<br>
<br>
&nbsp;&nbsp; How does connection collision gets resolved in BFD? What if 2
systems are<br>
trying to create BFD sessions to each other at the same time. Is there is a
possibility <br>
that we might land up with 2 sessions?<o:p></o:p></p>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<p class=3DMsoNormal>Regards,<br>
Sambath<o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BA957SJEXCHCCR02co_--


From sambath_kumar_b@yahoo.com  Thu Apr 15 14:39:22 2010
Return-Path: <sambath_kumar_b@yahoo.com>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4992A3A6908 for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 14:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.086
X-Spam-Level: **
X-Spam-Status: No, score=2.086 tagged_above=-999 required=5 tests=[AWL=1.750,  BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9kx2YuGjdMb for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 14:39:21 -0700 (PDT)
Received: from n2-vm1.bullet.mail.gq1.yahoo.com (n2-vm1.bullet.mail.gq1.yahoo.com [67.195.23.155]) by core3.amsl.com (Postfix) with SMTP id 4F7363A68C3 for <rtg-bfd@ietf.org>; Thu, 15 Apr 2010 14:39:21 -0700 (PDT)
Received: from [98.137.27.132] by n2.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2010 21:39:12 -0000
Received: from [98.137.27.216] by t4.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2010 21:39:12 -0000
Received: from [127.0.0.1] by omp126.mail.gq1.yahoo.com with NNFMP; 15 Apr 2010 21:39:12 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 296416.27853.bm@omp126.mail.gq1.yahoo.com
Received: (qmail 64593 invoked by uid 60001); 15 Apr 2010 21:39:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271367552; bh=Fl9KGNnDk2cmI8NkWJSJDRQsIsYLo0QvVIC3XiDDO4E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=f4u07o3VX8TIuXf5WLC2wLyVSxbmBDlps2ehbQOkPOpe+7/IIcxSmErAK89wGUPbSU1FkVh+5WQV5kSqOicAerAk+Jxytf3gLL8RPRFEIcVNf8wqgvewZXAIza7UmQ8PUlMpfVX+qcMGVbsUHlOsUkY8JtwXOW1nhPoVgmJMr9U=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=q0DPZ2RNGp/YR2glYkh8NFOvEYebLtze1EnO2A3BToT4/N/6HSqqrzWiDsK9kGEGQ54EWRrmXgr9P8jxk6TwCuaeHo70zszpa+2Z+1vuWuoBQUsk2AJmdxkcY+qZqUH9ioPaZzXUz3NEK7bAwrsV3V7CXms80zuHfoo3IdqQfNs=;
Message-ID: <174664.64580.qm@web180310.mail.gq1.yahoo.com>
X-YMail-OSG: MpWcLl0VM1mFrLMvo7ySsUu_yGNqtxW7FOX.LNlG8GYds2l .eeu8r67C4Pt9HevNyIkmOIfDcJ4l8i6l7np_orOBw0oWodrVh1hRbvvvAUg cpCOg4keo1VkVy5lN6WF9SY2_OX8xx5LKafITody5dDdxKKVn.DF7VPHtBI3 j89asF1AkUAD_5iP4WQaSwYddy0boEkMLRqFhCTWLb74RYGLrAHu5w71awAH rO8.2jVEEIdvmO0Pn2e9io3eNsx_ieMg_Fu50lx9eD2NS.fq4Y00KROQ.N1t Xlq_m3kvEdAWy_xKNY7iTjRRVGVla85iwAauCiI3_WCRi89eVLnlXHrRdeGs 0SRLG3o4ic1DyKFLefHKlHlkSAzEGRw--
Received: from [65.223.109.250] by web180310.mail.gq1.yahoo.com via HTTP; Thu, 15 Apr 2010 14:39:11 PDT
X-Mailer: YahooMailRC/348.3 YahooMailWebService/0.8.100.260964
References: <364645.31664.qm@web180310.mail.gq1.yahoo.com> <2C2F1EBA8050E74EA81502D5740B4BD693F03BA957@SJEXCHCCR02.corp.ad.broadcom.com>
Date: Thu, 15 Apr 2010 14:39:11 -0700 (PDT)
From: sambath kumar <sambath_kumar_b@yahoo.com>
Subject: Re: Connection collision in BFD
To: Shahram Davari <davari@broadcom.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Satyam Sinha <satyamsinha@live.com>
In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F03BA957@SJEXCHCCR02.corp.ad.broadcom.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1551328215-1271367551=:64580"
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 21:39:22 -0000

--0-1551328215-1271367551=:64580
Content-Type: text/plain; charset=us-ascii

Hi Shahram/ Satyam,

  Thanks for your answers. I realize now that it is system's responsibility to
tie the 2 streams together.

Regards,
Sambath




________________________________
From: Shahram Davari <davari@broadcom.com>
To: sambath kumar <sambath_kumar_b@yahoo.com>; "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Sent: Thu, April 15, 2010 2:18:21 PM
Subject: RE: Connection collision in BFD

 
Hi,
 
This is the normal operation when both systems are in Active
mode. It is the responsibility of each system to bind these two stream to each
other.
 
Regards,
Shahram
 
From:rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of sambath
kumar
Sent: Thursday, April 15, 2010 1:58 PM
To: rtg-bfd@ietf.org
Subject: Connection collision in BFD
 
Hi,

   How does connection collision gets resolved in BFD? What if 2
systems are
trying to create BFD sessions to each other at the same time. Is there is a
possibility 
that we might land up with 2 sessions?
 
Regards,
Sambath
--0-1551328215-1271367551=:64580
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt">Hi Shahram/ Satyam,<br><br>&nbsp; Thanks for your answers. I realize now that it is system's responsibility to<br>tie the 2 streams together.<br><br>Regards,<br>Sambath<br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Shahram Davari &lt;davari@broadcom.com&gt;<br><b><span style="font-weight: bold;">To:</span></b> sambath kumar &lt;sambath_kumar_b@yahoo.com&gt;; "rtg-bfd@ietf.org" &lt;rtg-bfd@ietf.org&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Thu, April 15, 2010 2:18:21 PM<br><b><span style="font-weight: bold;">Subject:</span></b> RE: Connection collision in
 BFD<br></font><br>



 
 
<style>
<!--
 
 _filtered {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;}
 _filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}
 _filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
 
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"serif";}
a:link, span.MsoHyperlink
	{color:blue;text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;text-decoration:underline;}
span.EmailStyle17
	{font-family:"sans-serif";color:#1F497D;}
.MsoChpDefault
	{font-size:10.0pt;}
 _filtered {margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{}
-->
</style>



<div class="Section1">

<p class="MsoNormal"><span style="font-size: 11pt; font-family: &quot;sans-serif&quot;; color: rgb(31, 73, 125);">Hi,</span></p> 

<p class="MsoNormal"><span style="font-size: 11pt; font-family: &quot;sans-serif&quot;; color: rgb(31, 73, 125);"> &nbsp;</span></p> 

<p class="MsoNormal"><span style="font-size: 11pt; font-family: &quot;sans-serif&quot;; color: rgb(31, 73, 125);">This is the normal operation when both systems are in Active
mode. It is the responsibility of each system to bind these two stream to each
other.</span></p> 

<p class="MsoNormal"><span style="font-size: 11pt; font-family: &quot;sans-serif&quot;; color: rgb(31, 73, 125);"> &nbsp;</span></p> 

<p class="MsoNormal"><span style="font-size: 11pt; font-family: &quot;sans-serif&quot;; color: rgb(31, 73, 125);">Regards,<br>
Shahram</span></p> 

<p class="MsoNormal"><span style="font-size: 11pt; font-family: &quot;sans-serif&quot;; color: rgb(31, 73, 125);"> &nbsp;</span></p> 

<div>

<div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;">

<p class="MsoNormal"><b><span style="font-size: 10pt; font-family: &quot;sans-serif&quot;;">From:</span></b><span style="font-size: 10pt; font-family: &quot;sans-serif&quot;;">
rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] <b>On Behalf Of </b>sambath
kumar<br>
<b>Sent:</b> Thursday, April 15, 2010 1:58 PM<br>
<b>To:</b> rtg-bfd@ietf.org<br>
<b>Subject:</b> Connection collision in BFD</span></p> 

</div>

</div>

<p class="MsoNormal"> &nbsp;</p> 

<div>

<p class="MsoNormal">Hi,<br>
<br>
&nbsp;&nbsp; How does connection collision gets resolved in BFD? What if 2
systems are<br>
trying to create BFD sessions to each other at the same time. Is there is a
possibility <br>
that we might land up with 2 sessions?</p> 

<div>

<p class="MsoNormal">&nbsp;</p> 

</div>

<p class="MsoNormal">Regards,<br>
Sambath</p> 

</div>

</div>

</div></div>
</div></body></html>
--0-1551328215-1271367551=:64580--


From dkatz@juniper.net  Thu Apr 15 21:13:05 2010
Return-Path: <dkatz@juniper.net>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C335C28C113 for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 21:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.184
X-Spam-Level: 
X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydnxwex57QnB for <rtg-bfd@core3.amsl.com>; Thu, 15 Apr 2010 21:13:02 -0700 (PDT)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id C1E5228C108 for <rtg-bfd@ietf.org>; Thu, 15 Apr 2010 21:13:01 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS8fjxfVuhKFPzeOEmunWaX34T8O7Ykhi@postini.com; Thu, 15 Apr 2010 21:12:55 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 15 Apr 2010 21:10:21 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Apr 2010 21:10:20 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Apr 2010 21:10:20 -0700
Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Apr 2010 21:10:20 -0700
Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13])	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o3G4AJb04523; Thu, 15 Apr 2010 21:10:19 -0700 (PDT)	(envelope-from dkatz@juniper.net)
Message-ID: <5D4BEB31-3433-4297-A551-365E1B0B3607@juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: sambath kumar <sambath_kumar_b@yahoo.com>
In-Reply-To: <174664.64580.qm@web180310.mail.gq1.yahoo.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-2-1026043412"
MIME-Version: 1.0 (Apple Message framework v936)
Subject: Re: Connection collision in BFD
Date: Thu, 15 Apr 2010 21:10:19 -0700
References: <364645.31664.qm@web180310.mail.gq1.yahoo.com> <2C2F1EBA8050E74EA81502D5740B4BD693F03BA957@SJEXCHCCR02.corp.ad.broadcom.com> <174664.64580.qm@web180310.mail.gq1.yahoo.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 16 Apr 2010 04:10:20.0373 (UTC) FILETIME=[BAA4C850:01CADD1A]
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 04:13:05 -0000

--Apple-Mail-2-1026043412
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

This functionality varies depending on the application of BFD.

In particular, this cannot happen in 1hop mode because of the way the  
demuxing is defined therein:

3. Initialization and Demultiplexing

    In this application, there will be only a single BFD session between
    two systems over a given interface (logical or physical) for a
    particular protocol.  The BFD session must be bound to this
    interface.  As such, both sides of a session MUST take the "Active"
    role (sending initial BFD Control packets with a zero value of Your
    Discriminator) and any BFD packet from the remote machine with a  
zero
    value of Your Discriminator MUST be associated with the session  
bound
    to the remote system, interface, and protocol.

So this works even when packets from both sides are in flight  
simultaneously, since each will have YourDisc == 0, and thus both will  
bind to the (only) session.  In this case it only takes one packet in  
each direction to complete the binding;  without the race condition it  
takes two packets in one direction and one packet in the other.


In multihop BFD, there are three scenarios spelled out in section 4.   
BFD-over-MPLS specifies the out-of-band approach.  Other multihop BFD  
usually uses the bind-single-session-to-address model, but in this  
case it is a little ambiguous.  Note that if one end thinks it is  
operating on a unidirectional link and the other end doesn't realize  
it via some out-of-band mechanism and so is doing address binding, the  
two ends will still convierge to a single session so long as the  
address on the undirectional sender end remains stable.  And if that  
address *does* change, there will temporarily be two sessions (until  
the first times out, since no more packets will be forthcoming from  
the old address.)  The implications of *that* are limited to nil,  
since it is up to whatever application/protocol is listening to the  
BFD "service" to know which session to bind to.  Either that  
application will be address agile (and will know the session to bind  
to) or it will fail on its own due to the address change.

--Dave



On Apr 15, 2010, at 2:39 PM, sambath kumar wrote:

> Hi Shahram/ Satyam,
>
>   Thanks for your answers. I realize now that it is system's  
> responsibility to
> tie the 2 streams together.
>
> Regards,
> Sambath
>
> From: Shahram Davari <davari@broadcom.com>
> To: sambath kumar <sambath_kumar_b@yahoo.com>; "rtg-bfd@ietf.org" <rtg-bfd@ietf.org 
> >
> Sent: Thu, April 15, 2010 2:18:21 PM
> Subject: RE: Connection collision in BFD
>
> Hi,
>
> This is the normal operation when both systems are in Active mode.  
> It is the responsibility of each system to bind these two stream to  
> each other.
>
> Regards,
> Shahram
>
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On  
> Behalf Of sambath kumar
> Sent: Thursday, April 15, 2010 1:58 PM
> To: rtg-bfd@ietf.org
> Subject: Connection collision in BFD
>
> Hi,
>
>    How does connection collision gets resolved in BFD? What if 2  
> systems are
> trying to create BFD sessions to each other at the same time. Is  
> there is a possibility
> that we might land up with 2 sessions?
>
> Regards,
> Sambath


--Apple-Mail-2-1026043412
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">This functionality varies =
depending on the application of BFD.<div><br></div><div>In particular, =
this cannot happen in 1hop mode because of the way the demuxing is =
defined therein:</div><div><br></div><div><div>3. Initialization and =
Demultiplexing</div><div><br></div><div>&nbsp;&nbsp; In this =
application, there will be only a single BFD session =
between</div><div>&nbsp;&nbsp; two systems over a given interface =
(logical or physical) for a</div><div>&nbsp;&nbsp; particular protocol. =
&nbsp;The BFD session must be bound to this</div><div>&nbsp;&nbsp; =
interface. &nbsp;As such, both sides of a session MUST take the =
"Active"</div><div>&nbsp;&nbsp; role (sending initial BFD Control =
packets with a zero value of Your</div><div>&nbsp;&nbsp; Discriminator) =
and any BFD packet from the remote machine with a =
zero</div><div>&nbsp;&nbsp; value of Your Discriminator MUST be =
associated with the session bound</div><div>&nbsp;&nbsp; to the remote =
system, interface, and protocol.</div><div><br></div><div>So this works =
even when packets from both sides are in flight simultaneously, since =
each will have YourDisc =3D=3D 0, and thus both will bind to the (only) =
session. &nbsp;In this case it only takes one packet in each direction =
to complete the binding; &nbsp;without the race condition it takes two =
packets in one direction and one packet in the =
other.</div><div><br></div><div><br></div><div>In multihop BFD, there =
are three scenarios spelled out in section 4. &nbsp;BFD-over-MPLS =
specifies the out-of-band approach. &nbsp;Other multihop BFD usually =
uses the bind-single-session-to-address model, but in this case it is a =
little ambiguous. &nbsp;Note that if one end thinks it is operating on a =
unidirectional link and the other end doesn't realize it via some =
out-of-band mechanism and so is doing address binding, the two ends will =
still convierge to a single session so long as the address on the =
undirectional sender end remains stable. &nbsp;And if that address =
*does* change, there will temporarily be two sessions (until the first =
times out, since no more packets will be forthcoming from the old =
address.) &nbsp;The implications of *that* are limited to nil, since it =
is up to whatever application/protocol is listening to the BFD "service" =
to know which session to bind to. &nbsp;Either that application will be =
address agile (and will know the session to bind to) or it will fail on =
its own due to the address =
change.</div><div><br></div><div>--Dave</div><div><br></div></div><div><br=
></div><div><br><div><div>On Apr 15, 2010, at 2:39 PM, sambath kumar =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font-family: 'times new roman', =
'new york', times, serif; font-size: 12pt; ">Hi Shahram/ =
Satyam,<br><br>&nbsp; Thanks for your answers. I realize now that it is =
system's responsibility to<br>tie the 2 streams =
together.<br><br>Regards,<br>Sambath<br><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font-family: =
'times new roman', 'new york', times, serif; font-size: 12pt; "><br><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font-family: 'times new roman', 'new york', times, =
serif; font-size: 12pt; "><font face=3D"Tahoma" size=3D"2"><hr =
size=3D"1"><b><span style=3D"font-weight: bold; ">From:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Shahram Davari &lt;<a =
href=3D"mailto:davari@broadcom.com" style=3D"color: blue; =
text-decoration: underline; ">davari@broadcom.com</a>&gt;<br><b><span =
style=3D"font-weight: bold; ">To:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>sambath kumar &lt;<a =
href=3D"mailto:sambath_kumar_b@yahoo.com" style=3D"color: blue; =
text-decoration: underline; ">sambath_kumar_b@yahoo.com</a>&gt;; "<a =
href=3D"mailto:rtg-bfd@ietf.org" style=3D"color: blue; text-decoration: =
underline; ">rtg-bfd@ietf.org</a>" &lt;<a href=3D"mailto:rtg-bfd@ietf.org"=
 style=3D"color: blue; text-decoration: underline; =
">rtg-bfd@ietf.org</a>&gt;<br><b><span style=3D"font-weight: bold; =
">Sent:</span></b><span class=3D"Apple-converted-space">&nbsp;</span>Thu, =
April 15, 2010 2:18:21 PM<br><b><span style=3D"font-weight: bold; =
">Subject:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>RE: Connection collision in =
BFD<br></font><br><div class=3D"Section1" style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: serif; "><span =
style=3D"font-size: 11pt; font-family: sans-serif; color: rgb(31, 73, =
125); ">Hi,</span></div><p class=3D"MsoNormal" style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: serif; "><span style=3D"font-size: 11pt; font-family: =
sans-serif; color: rgb(31, 73, 125); ">&nbsp;</span></p><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: serif; "><span =
style=3D"font-size: 11pt; font-family: sans-serif; color: rgb(31, 73, =
125); ">This is the normal operation when both systems are in Active =
mode. It is the responsibility of each system to bind these two stream =
to each other.</span></div><p class=3D"MsoNormal" style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: serif; "><span style=3D"font-size: 11pt; =
font-family: sans-serif; color: rgb(31, 73, 125); =
">&nbsp;</span></p><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
serif; "><span style=3D"font-size: 11pt; font-family: sans-serif; color: =
rgb(31, 73, 125); ">Regards,<br>Shahram</span></div><p class=3D"MsoNormal"=
 style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: serif; "><span =
style=3D"font-size: 11pt; font-family: sans-serif; color: rgb(31, 73, =
125); ">&nbsp;</span></p><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
border-top-width: 1pt; border-right-width: medium; border-bottom-width: =
medium; border-left-width: medium; border-top-style: solid; =
border-right-style: none; border-bottom-style: none; border-left-style: =
none; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; =
padding-left: 0in; "><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
serif; "><b><span style=3D"font-size: 10pt; font-family: sans-serif; =
">From:</span></b><span style=3D"font-size: 10pt; font-family: =
sans-serif; "><span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:rtg-bfd-bounces@ietf.org">rtg-bfd-bounces@ietf.org</a> =
[<a href=3D"mailto:rtg-bfd-bounces@ietf.org" style=3D"color: blue; =
text-decoration: underline; ">mailto:rtg-bfd-bounces@ietf.org</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><b>On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></b>sambath =
kumar<br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Thursday, April 15, 2010 =
1:58 PM<br><b>To:</b><span class=3D"Apple-converted-space">&nbsp;</span><a=
 href=3D"mailto:rtg-bfd@ietf.org" style=3D"color: blue; text-decoration: =
underline; ">rtg-bfd@ietf.org</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Connection collision in =
BFD</span></div></div></div><p class=3D"MsoNormal" style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: serif; ">&nbsp;</p><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: serif; =
">Hi,<br><br>&nbsp;&nbsp; How does connection collision gets resolved in =
BFD? What if 2 systems are<br>trying to create BFD sessions to each =
other at the same time. Is there is a possibility<span =
class=3D"Apple-converted-space">&nbsp;</span><br>that we might land up =
with 2 sessions?</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><p class=3D"MsoNormal" =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: serif; =
">&nbsp;</p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
serif; =
">Regards,<br>Sambath</div></div></div></div></div></div></div></blockquot=
e></div><br></div></body></html>=

--Apple-Mail-2-1026043412--

From nobo@cisco.com  Mon Apr 26 02:00:20 2010
Return-Path: <nobo@cisco.com>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2643A6A35 for <rtg-bfd@core3.amsl.com>; Mon, 26 Apr 2010 02:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level: 
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzBlSuSlr9SJ for <rtg-bfd@core3.amsl.com>; Mon, 26 Apr 2010 02:00:19 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 22F9B3A6A2E for <rtg-bfd@ietf.org>; Mon, 26 Apr 2010 02:00:19 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAL3y1EurR7Hu/2dsb2JhbACcNnGnB5kegniCFASDOQ
X-IronPort-AV: E=Sophos;i="4.52,272,1270425600"; d="scan'208";a="252406797"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2010 09:00:05 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3Q905A3005018; Mon, 26 Apr 2010 09:00:05 GMT
Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 26 Apr 2010 02:00:05 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Comments on draft-ietf-bfd-mib-09
Date: Mon, 26 Apr 2010 02:00:03 -0700
Message-ID: <F3F69139C275F848A1DB1518DC2C21680A1B0523@xmb-sjc-22c.amer.cisco.com>
In-Reply-To: <20100320174659.GD31380@slice>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-bfd-mib-09
Thread-Index: AcrIVWRppZZDKeMhS0eVS7NZZsiuigct/wTg
References: <20100320174659.GD31380@slice>
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: "Jeffrey Haas" <jhaas@pfrc.org>, <tom.nadeau@bt.com>, "Zafar Ali (zali)" <zali@cisco.com>
X-OriginalArrivalTime: 26 Apr 2010 09:00:05.0383 (UTC) FILETIME=[DD0C4970:01CAE51E]
Cc: rtg-bfd@ietf.org
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 09:00:20 -0000

Hello Jeffrey,

Thanx for comments & my apologies for delay.

Please see inline for reply to each item.

> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20
> Sent: Sunday, March 21, 2010 2:47 AM
> To: tom.nadeau@bt.com; Zafar Ali (zali); Nobo Akiya (nobo)
> Cc: rtg-bfd@ietf.org
> Subject: Comments on draft-ietf-bfd-mib-09
>=20
> Authors:
>=20
> These comments are as an individual contributor rather than=20
> in my role of BFD co-chair.
>=20
> I have not run the mib through snmplint.
>=20
> ---
>=20
> Regarding bfdSessType, I realize this has been in the MIB for=20
> a while in the context of the type of multi-hop session. =20
> However, I'd like to suggest that this is heading for a=20
> collision with likely future working group tasks.  In this=20
> case, it would be draft-katz-ward-bfd-multipoint.  That draft=20
> defines a new BFD variable meant to cover the BFD session=20
> type.  Further, that type covers semantics that don't overlap=20
> well with those currently covered by bfdSessType.
>=20
> The current object describes the session in terms of its=20
> mult-hop properties.  While this is potentially useful for=20
> helping a MIB consumer understand some of the session=20
> properties and why some of the various other objects have=20
> their current values, it's somewhat problematic in terms of=20
> configuring a session from the MIB.  I can see why OOB would=20
> only occur for BFD sessions created by other applications=20
> (e.g. OSPF, LSP-PING), however it's unclear how the MIB=20
> implementation should handle setting this variable for other=20
> MIB-created sessions.
>=20
> This object could use some additional clarification text to=20
> cover the use cases.  I'd also suggest factoring it out into=20
> a textual convention.

Most implementations explicitly state whether the session session is
singlehop or multihop, and this object goes gand-in-hand with that. It
probably doesn't hurt to be in there. ACK on TC.

>=20
> Similarly, the bfdSessMultiHopUniLinkMode object could use=20
> clarification for its use cases - in particular why it's=20
> read-only instead of read-create.
> This object, name aside, seems potentially useful for setting=20
> a BFD session to be active instead of passive.  If that's the=20
> intention I'd suggest making it read-create and deleting the=20
> MultiHopUniLink portion of the name.  This would require=20
> clarification about acceptable values for certain types of sessions.

This object was added with BFD-MPLS in mind, but immediate goal for this
draft should be to complete this draft for BFD-IP. Best to take out this
object for now. Please see (ref#1) below for more explanations.

>=20
> bfdSessSourceUdpPort is constrained by the BFD specifciations=20
> to be limited to values 49152..65535.  I don't recall if=20
> ranges can be applied to a textual convention - I suspect you=20
> would need to to create a new one to cover these=20
> restrictions.  Also, given the above, the DEFVAL should be=20
> adjusted or clarified.  For example, 0 would permit the SNMP=20
> agent to choose its own source port.

ACK.

>=20
> The DEFVAL for bfdSessEchoSourceUdpPort when 0 should be=20
> similarly clarified.

ACK.

>=20
> I would suggest that the SYNTAX of the bfdSessState object be=20
> put into a TEXTUAL-CONVENTION. =20

ACK.

>=20
> bfdSessDiag is accessible-for-notify rather than read-only. =20
> Is there a reason why the user wouldn't want to see this=20
> status in a MIB poll?

ACK to change to read-only.

>=20
> bfdSessOperMode has semantics that may end up being=20
> incompatible with draft-katz-war-bfd-multipoint.  That=20
> document is not yet a working group item, but I'd suggest=20
> considering how such a document would impact this object. =20
> Perhaps factoring this into a TEXTUAL-CONVENTION would make sense.
>=20
> Additionally, bfdSessOperMode is read-only.  Why wouldn't=20
> this be read-create?

Demand mode is orthogonal to the operational status, thus probably good
that this configuration be available. ACK to create TC and change to
read-create.

>=20
> bfdSessMultiPointFlag is included in this MIB as a read-only=20
> object.  Given that the semantics and impact of this flag are=20
> covered by draft-katz-ward-bfd-multipoint, would you suggest:
> 1. Keeping the object in here, read-only?
> 2. Updating it to read-create and plan on updating the base=20
> BFD MIB to accomodate the draft if it is adopted as a WG item?
> 3. Remove the object and plan on making the multipoint=20
> changes as AUGMENTation tables to the base MIB?

Good point. 2 sounds like the way to go.

>=20
> For bfdSessGTSMTTL, what are the semantics you expect a 0 TTL=20
> to have (the DEFVAL)?  Should this be 0 only if GTSM is=20
> disabled in bfdSessGTSM?

Good point, 0 should indicate GTSM disabled. Description will be
updated.

>  Also, you should consider updating=20
> the DESCRIPTION to accommodate requirements of bfd-mpls where=20
> the TTL of the bottom label MUST be 1.

There's been split opinions about whether this draft should support
BFD-IP only or should include BFD-MPLS as well. This is something that
we need WG to help decide. Until it is decided, we will focus on
completing this draft to be BFD-IP only. (ref#1)

>=20
> In bfdSessDesiredMinTxInterval, consider adding text to the=20
> DESCRIPTION to note that a value of 0 disables transmitting=20
> periodic control packets from BFD.

For bfdSessDesiredMinTxInterval, value of 0 is reserved according to the
base spec. We can specify that instead. As for bfdSessReqMinRxInterval,
value of 0 will indicate the remote to not send any control packets,
again according to base spec. We can specify that.

>=20
> Similarly in bfdSessReqMinEchoRxInterval, consider adding=20
> text to the DESCRIPTION to note that a value of 0 indicates=20
> that no echo traffic is desired and this value MUST be 0 for=20
> multi-hop sessions.

ACK.

>=20
> bfdSessAuthPresFlag is read-only.  Since it's in the=20
> read-write conformance group, I suspect this is an error.  If=20
> that's not the case, you should add text to the DESCRIPTION=20
> to clarify its value in the presence of the configuration of=20
> bfdSessAuthentication(Type|KeyId|Key).

ACK to change to read-create.

>=20
> bfdSessAuthentiacationType probably should call out value 0=20
> as being used when no authentication is in use.  I would also=20
> suggest factoring the SYNTAX into a TEXTUAL-CONVENTION.

ACK. Since 0 is reserved, probably best to define -1 as
no-authentication.

>=20
> bfdSessAuthenticationKey carries a *lot* of semantics that=20
> should vary depending on the authentication type.  While the=20
> valid range of the field could be 0..252 based on the PDU=20
> description, the values are constrained based on the type:
> - Password: 1..16
> - MD5: 16
> - SHA-1: 20
>=20
> I would suggest creating a TEXTUAL-CONVENTION that describes=20
> these semantics.

Let me check with other folks on this one.

>=20
> bfdSessPerfEntry: s/bfdCounterDiscontinuityTime/bfdSessPerfDiscTime/

ACK.

>=20
> In bfdSessDiscMapIndex and bfdSessIpMapIndex, I think you=20
> mean BfdSessIndexTC instead of BfdIndex, correct?

Yes, ACK.

>=20
> In bfdSessIpMapTable, shouldn't the table apply to multi-hop=20
> types as well?

That's a good point. Leaving aside virtualization of MIB modules, we are
missing the IP source address. We will add this in bfdSessTable as well
as bfdSessIpMapTable .

>=20
> In the Security Considerations, where bfdSessPerfTable is=20
> mentioned, it should also mention bfdSessPerfHCTable.

We are ok here, as there is no bfdSessPerfHCTable, high capacity
counters are part of bfdSessPerfTable.

>=20
> ---
>=20
> Conformance Group issues:
>=20
> bfdSessDiscMapTable is not in a conformance group=20
> bfdsessIpMapTable is not in a conformance group

Table names shouldn't appear in the conformance statement.

>=20
> bfdSessionPerfHCGroup and bfdNotificationGroup should not be=20
> in both a GROUP clause and in MANDATORY-GROUPS. =20
>=20
> bfdNotificationGroup sounds like it is meant to be optional=20
> and probably should be excluded from MANDATORY-GROUPS.

ACK to remove bfdSessionPerfHCGroup from MANDATORY-GROUPS.
bfdNotificationGroup should belong in  MANDATORY-GROUPS, will make
changes accordingly.

>=20
> ---
>=20
> Editorial nits:
> In section 5.3:
> "   The session performance table is used for collecting BFD=20
> performance
>    counts on a per session basis."
>=20
> s/counts/counters/

ACK.

>=20
> In section 5.5:
>=20
> "   BfdSessIndexTC used in the bfdSessionTable.  This table SHOULD
>    contains those BFD sessions are of IP type."
>=20
> "that are of IP type".

ACK.

>=20
>     BfdInterval ::=3D TEXTUAL-CONVENTION
>     DISPLAY-HINT   "d"
>     STATUS         current
>     DESCRIPTION
>         "The BFD interval delay in microseconds."
>=20
> I'd suggest deleting "delay".

ACK.

>=20
> In bfdSessAddr:
> "             It can also be used to enabled BFD on a specific"
>=20
> s/enabled/enable/

ACK.

Thanx,
Nobo

>=20

From dai.xuehui@zte.com.cn  Wed Apr 28 01:49:33 2010
Return-Path: <dai.xuehui@zte.com.cn>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9103A67B2; Wed, 28 Apr 2010 01:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.439
X-Spam-Level: 
X-Spam-Status: No, score=-97.439 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MISSING_SUBJECT=1.762, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COWSPUJmd2-J; Wed, 28 Apr 2010 01:49:32 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C6C253A65A6; Wed, 28 Apr 2010 01:49:31 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887813339890; Wed, 28 Apr 2010 16:45:08 +0800 (CST)
Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.3729454058; Wed, 28 Apr 2010 16:49:12 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3S8keeZ029300; Wed, 28 Apr 2010 16:49:03 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn)
MIME-Version: 1.0
X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:53:50, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:53:50, Serialize complete at 2010-04-28 16:53:50, S/MIME Sign failed at 2010-04-28 16:53:51:  =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:54:16, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:54:16, Serialize complete at 2010-04-28 16:54:16, S/MIME Sign failed at 2010-04-28 16:54:16:  =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:48:53, Serialize complete at 2010-04-28 16:48:53
To: rahul@juniper.net, kireeti@juniper.net, swallow@cisco.com
Subject: 
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF185DED03.EFAA1726-ON48257713.002D8903-48257713.0030EA23@zte.com.cn>
From: dai.xuehui@zte.com.cn
Date: Wed, 28 Apr 2010 16:46:50 +0800
Content-Type: multipart/alternative; boundary="=_alternative 0030EA2148257713_="
X-MAIL: mse2.zte.com.cn o3S8keeZ029300
Cc: mpls@ietf.org, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 08:49:33 -0000

This is a multipart message in MIME format.
--=_alternative 0030EA2148257713_=
Content-Type: text/plain; charset="US-ASCII"

Hi all,

In RFC4379, Section 4.3 - "Sending an MPLS Echo Request", The Router Alert 
option MUST be set in the IP header.

In draft-ietf-bfd-mpls-07, section-7 "Encapsulation", I can *NOT* find 
anything about "the Router Alert Option".

IMO, the MPLS-BFD refer to RFC4379; why are they  *NOT* the same on the 
operation of "Router Alert Option"? 




Best Regards.

--=_alternative 0030EA2148257713_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5IaSBhbGwsPC9mb250Pg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9MyBmYWNlPSJAy87M5SI+SW4gUkZDNDM3OSwgU2VjdGlvbiA0LjMgLSAmcXVv
dDtTZW5kaW5nDQphbiBNUExTIEVjaG8gUmVxdWVzdCZxdW90OywgVGhlIFJvdXRlciBBbGVydCBv
cHRpb24gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iQMvOzOUiPk1VU1Q8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj4NCmJlIHNldCBpbiB0aGUgSVAgaGVhZGVyLjwv
Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQMvOzOUiPkluIGRyYWZ0LWlldGYt
YmZkLW1wbHMtMDcsIHNlY3Rpb24tNyAmcXVvdDtFbmNhcHN1bGF0aW9uJnF1b3Q7LA0KSSBjYW4g
Kk5PVCogZmluZCBhbnl0aGluZyBhYm91dCAmcXVvdDt0aGUgUm91dGVyIEFsZXJ0IE9wdGlvbiZx
dW90Oy48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5JTU8sIHRo
ZSBNUExTLUJGRCByZWZlciB0byBSRkM0Mzc5OyB3aHkNCmFyZSB0aGV5ICZuYnNwOypOT1QqIHRo
ZSBzYW1lIG9uIHRoZSBvcGVyYXRpb24gb2YgJnF1b3Q7Um91dGVyIEFsZXJ0IE9wdGlvbiZxdW90
Oz8NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdhcmRzLjxicj4NCjwvZm9udD4NCg==
--=_alternative 0030EA2148257713_=--


From dai.xuehui@zte.com.cn  Wed Apr 28 01:51:08 2010
Return-Path: <dai.xuehui@zte.com.cn>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D088C3A65A6; Wed, 28 Apr 2010 01:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.32
X-Spam-Level: 
X-Spam-Status: No, score=-98.32 tagged_above=-999 required=5 tests=[AWL=0.881,  BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001,  MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcBp-YpZA-VX; Wed, 28 Apr 2010 01:51:08 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 7C0233A68E4; Wed, 28 Apr 2010 01:51:07 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887813339890; Wed, 28 Apr 2010 16:46:19 +0800 (CST)
Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.3729454058; Wed, 28 Apr 2010 16:50:51 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3S8oOVs037057; Wed, 28 Apr 2010 16:50:26 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn)
To: rahul@juniper.net, kireeti@juniper.net, swallow@cisco.com
Subject: doubt about "IP Router Alert Option" between MPLS-BFD & LSP-Ping
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF20275A61.E56A7C65-ON48257713.0030454B-48257713.00310AE3@zte.com.cn>
From: dai.xuehui@zte.com.cn
Date: Wed, 28 Apr 2010 16:48:14 +0800
X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:55:40, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:55:40, Serialize complete at 2010-04-28 16:55:40, S/MIME Sign failed at 2010-04-28 16:55:40: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:50:16, Serialize complete at 2010-04-28 16:50:16
Content-Type: multipart/alternative; boundary="=_alternative 00310AE148257713_="
X-MAIL: mse2.zte.com.cn o3S8oOVs037057
Cc: mpls@ietf.org, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 08:51:08 -0000

This is a multipart message in MIME format.
--=_alternative 00310AE148257713_=
Content-Type: text/plain; charset="US-ASCII"

Hi all,

In RFC4379, Section 4.3 - "Sending an MPLS Echo Request", The Router Alert 
option MUST be set in the IP header.

In draft-ietf-bfd-mpls-07, section-7 "Encapsulation", I can *NOT* find 
anything about "the Router Alert Option".

IMO, the MPLS-BFD refer to RFC4379; why are they  *NOT* the same on the 
operation of "Router Alert Option"?


BR.
Xuehui

--=_alternative 00310AE148257713_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5IaSBhbGwsPC9mb250Pg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9MyBmYWNlPSJAy87M5SI+SW4gUkZDNDM3OSwgU2VjdGlvbiA0LjMgLSAmcXVv
dDtTZW5kaW5nDQphbiBNUExTIEVjaG8gUmVxdWVzdCZxdW90OywgVGhlIFJvdXRlciBBbGVydCBv
cHRpb24gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iQMvOzOUiPk1VU1Q8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj4NCmJlIHNldCBpbiB0aGUgSVAgaGVhZGVyLjwv
Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQMvOzOUiPkluIGRyYWZ0LWlldGYt
YmZkLW1wbHMtMDcsIHNlY3Rpb24tNyAmcXVvdDtFbmNhcHN1bGF0aW9uJnF1b3Q7LA0KSSBjYW4g
Kk5PVCogZmluZCBhbnl0aGluZyBhYm91dCAmcXVvdDt0aGUgUm91dGVyIEFsZXJ0IE9wdGlvbiZx
dW90Oy48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5JTU8sIHRo
ZSBNUExTLUJGRCByZWZlciB0byBSRkM0Mzc5OyB3aHkNCmFyZSB0aGV5ICZuYnNwOypOT1QqIHRo
ZSBzYW1lIG9uIHRoZSBvcGVyYXRpb24gb2YgJnF1b3Q7Um91dGVyIEFsZXJ0IE9wdGlvbiZxdW90
Oz88L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PkJSLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WHVlaHVpPGJy
Pg0KPC9mb250Pg0K
--=_alternative 00310AE148257713_=--