From sambath_kumar_b@yahoo.com Thu Apr 15 13:58:10 2010 Return-Path: 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 ; 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 ; 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 ; 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 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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-- From satyamsinha@live.com Thu Apr 15 14:17:36 2010 Return-Path: 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 ; 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 ; 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 ; 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: Content-Type: multipart/alternative; boundary="_42a41c7e-7347-4a56-876e-de0aa061d53e_" X-Originating-IP: [64.47.51.158] From: Satyam Sinha To: , 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Hi Sambath=2C

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.

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

Rega= rds=2C

Satyam



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

Hi=2C

 =3B =3B 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?
 =3B
Regards=2C
= Sambath

Hotmail is redefining busy with to= ols for the New Busy. Get more from your inbox. See how. = --_42a41c7e-7347-4a56-876e-de0aa061d53e_-- From davari@broadcom.com Thu Apr 15 14:19:41 2010 Return-Path: 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 ; 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 ; 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 ; 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" To: "sambath kumar" , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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 e= ach 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

--_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BA957SJEXCHCCR02co_-- From sambath_kumar_b@yahoo.com Thu Apr 15 14:39:22 2010 Return-Path: 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 ; 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 ; 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 ; 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 Subject: Re: Connection collision in BFD To: Shahram Davari , "rtg-bfd@ietf.org" , Satyam Sinha 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: sambath kumar ; "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
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-- From dkatz@juniper.net Thu Apr 15 21:13:05 2010 Return-Path: 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 ; 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 ; 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 ; 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 To: sambath kumar 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" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 > To: sambath kumar ; "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 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 =3D=3D 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" < Thu, = April 15, 2010 2:18:21 PM
 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

 

 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

 

 
that we might land up = with 2 sessions?

Regards,
Sambath


= --Apple-Mail-2-1026043412-- From nobo@cisco.com Mon Apr 26 02:00:20 2010 Return-Path: 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 ; 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 ; 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 ; 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: 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)" To: "Jeffrey Haas" , , "Zafar Ali (zali)" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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: 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" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: 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: 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" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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_=--