From nobo@cisco.com Mon Oct 7 07:12:19 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C33721E80AF for ; Mon, 7 Oct 2013 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vkrMPb3RQJN for ; Mon, 7 Oct 2013 07:12:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 77BE921E80AB for ; Mon, 7 Oct 2013 07:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1902; q=dns/txt; s=iport; t=1381155133; x=1382364733; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZI1jNhRUMk5UeQYpQTS9yKIbBSvF+hp/Qze/FR0lq+U=; b=bNN2HAMUIqkX/pCKa6ZcUPudCcb37yDHB1wV2SfqDXJUHWXdFp2d79vd /rVRCJI8t03F5KMiygTUVF66H2IzHfY7S1ySCv3UmECKkuRIFY0t+FucQ 5nE3Md8zlUPFuEO78OjeTFORTW51qSWaeS/0LUGei7hfYneOVakTCrrrt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscFANu/UlKtJXG//2dsb2JhbABZgmYhOFKDKL1yF4EHFm0HgiUBAQEEIxFRBAIBGQQBAQMCBh0DAgICMBQBCAgCBBMIh34BC6g1khQEgSmNdzgGgmQ1gQQDqgGDJIIq X-IronPort-AV: E=Sophos;i="4.90,1050,1371081600"; d="scan'208";a="268978175" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 07 Oct 2013 14:12:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r97ECAPv018705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Oct 2013 14:12:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 7 Oct 2013 09:12:10 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: IETF 88 Preliminary Agenda Thread-Topic: IETF 88 Preliminary Agenda Thread-Index: AQHOwVTs6jSbyu5LmECL8ko6V6vRTpnpSn3Q Date: Mon, 7 Oct 2013 14:12:10 +0000 Message-ID: References: <20131004225500.32223.56827.idtracker@ietfa.amsl.com> In-Reply-To: <20131004225500.32223.56827.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 14:12:19 -0000 RGVhciBCRkQgV0cgTWVtYmVycywNCg0KUHJlbGltaW5hcnkgYWdlbmRhIGZvciBWYW5jb3V2ZXIg aGFzIGJlZW4gcHVibGlzaGVkLg0KDQpJZiB0aGVyZSBhcmUgbm8gY2hhbmdlcywgQkZEIFdHIGlz IHNjaGVkdWxlZCB0byBtZWV0IE1vbmRheSBOb3YgNCwgYXQgOTowMC0xMTozMC4NCjZtYW4sIG52 bzMsIGFwcHNhd2csIG1tdXNpYywgbmV0Y29uZiwgdGNwbSBhcmUgbWVldGluZyBpbiBwYXJhbGxl bC4NCg0KLU5vYm8NCmZvciB0aGUgV0cgQ2hhaXJzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogd2djaGFpcnMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOndnY2hhaXJz LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBJRVRGIEFnZW5kYQ0KPiBTZW50OiBG cmlkYXksIE9jdG9iZXIgMDQsIDIwMTMgNjo1NSBQTQ0KPiBUbzogV29ya2luZyBHcm91cCBDaGFp cnMNCj4gQ2M6IGlyc2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogSUVURiA4OCBQcmVsaW1pbmFyeSBB Z2VuZGENCj4gDQo+IE5PVEU6IFlvdSB3aWxsIG5vdCByZWNlaXZlIGFuIGF1dG9tYXRpYyBub3Rp ZmljYXRpb24gaW5mb3JtaW5nIHlvdSB0aGF0IHlvdXINCj4gc2Vzc2lvbiBoYXMgYmVlbiBzY2hl ZHVsZWQuICBQbGVhc2Ugc2VlDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy84OC9hZ2VuZGEuaHRtbCB0byBkZXRlcm1pbmUgdGhlDQo+IHRpbWUocykgb2YgeW91ciBzZXNz aW9uKHMpLiAgVGhlIGF1dG9tYXRpYyBub3RpZmljYXRpb24gb2Ygc2NoZWR1bGVkIHNlc3Npb25z DQo+IHdpbGwgcmV0dXJuIGZvciBJRVRGIDg5Lg0KPiANCj4gVGhlIElFVEYgODggcHJlbGltaW5h cnkgYWdlbmRhIGhhcyBiZWVuIHBvc3RlZC4gIFRoZSBmaW5hbCBhZ2VuZGEgd2lsbCBiZQ0KPiBw dWJsaXNoZWQgb24gRnJpZGF5LCBPY3RvYmVyIDExdGguDQo+IA0KPiBJZiB5b3Ugd291bGQgbGlr ZSB0byByZXF1ZXN0IGEgY2hhbmdlIHRvIHRoZSBwcmVsaW1pbmFyeSBhZ2VuZGEsIHBsZWFzZQ0K PiBzZW5kIGEgbWVzc2FnZSB0byBhZ2VuZGFAaWV0Zi5vcmcgYW5kIGNvcHkgYWxsIHJlbGV2YW50 IEFyZWEgRGlyZWN0b3JzLg0KPiANCj4gUGxlYXNlIG5vdGUgdGhlIGN1dG9mZiBkYXRlIGZvciBy ZXF1ZXN0cyB0byByZXNjaGVkdWxlIFdvcmtpbmcgR3JvdXAgYW5kDQo+IEJPRiBtZWV0aW5ncyBp cyBPY3RvYmVyIDd0aCwgMjAxMyBhdCBVVEMgMjQ6MDAuDQo+IA0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvODgvYWdlbmRhLmh0bWwNCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9tZWV0aW5nLzg4L2FnZW5kYS50eHQNCj4gDQo+IFRoYW5rIHlvdSENCj4gDQo+ IElFVEYgU2VjcmV0YXJpYXQNCg== From nobo@cisco.com Tue Oct 8 15:52:06 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F4521F9DA3 for ; Tue, 8 Oct 2013 15:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7JaWdHOnBmd for ; Tue, 8 Oct 2013 15:52:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9F40921F9BCE for ; Tue, 8 Oct 2013 15:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=644; q=dns/txt; s=iport; t=1381272719; x=1382482319; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=iaAV3yRTJi0V897EosJQ18rp9wGQQzk9EIUjGdG0kcs=; b=ZUL/4mIaej9pw32yRQpLhTThvWA6RIukZCiOwUkeSnGiRDS4o6kdj4Hs X6xLLqmU5ndMAK9kIxdSXBfkCj8XSlI1DfaOjC+gFO+RbretpJFlzCB8f QNI3+TPOcguqrdbjqUxuTJo2rELfHgOHX1WWFDwgSycn1KebvefiISxtj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FALmDVFKtJXG8/2dsb2JhbABZgmYhOFLBKYEmFm0HgicBBDo/EgEqFEImAQQODYd+AQu6LASOCYEIMQKDJIEEA6oBgySBcTk X-IronPort-AV: E=Sophos;i="4.90,1059,1371081600"; d="scan'208";a="266723429" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 08 Oct 2013 22:51:59 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r98MpxDj027299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 22:51:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 17:51:58 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Slots requests for BFD WG session - IETF 88 - Vancouver Thread-Topic: Slots requests for BFD WG session - IETF 88 - Vancouver Thread-Index: Ac7Ed/8d3UJW3NiqSrSAqpB4WBJuew== Date: Tue, 8 Oct 2013 22:51:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeff Haas \(jhaas@juniper.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:52:06 -0000 Dear BFD WG Members, It is time to start building the BFD WG agenda for Vancouver. The current IETF agenda, still subject to change, is available at: https://datatracker.ietf.org/meeting/88/agenda.html The BFD WG session is for the moment scheduled on: Monday Nov 4, at 9:00-11:30 Although Jeff and I anticipate the session will not take the entire 2.5 hou= rs. Please send Jeff Haas and myself (replying to this e-mail) your request for= a presentation slot, indicating: Draft name Speaker Desired duration (covering presentation + Q&As). Please send the requests before the 22nd of October. -Nobo for the WG Chairs From Evgeny.Sandler@ecitele.com Wed Oct 9 06:07:48 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC22611E8183 for ; Wed, 9 Oct 2013 06:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qmot4rV8S7f for ; Wed, 9 Oct 2013 06:07:42 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0667C21F9CAD for ; Wed, 9 Oct 2013 06:07:37 -0700 (PDT) X-AuditID: 93eaf2e7-b7f7c6d000002a4c-2d-525555183896 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7E.F0.10828.81555525; Wed, 9 Oct 2013 15:07:36 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Wed, 9 Oct 2013 16:07:36 +0300 From: Evgeny Sandler To: "rtg-bfd@ietf.org" Subject: Question on bfd.LocalDiag variable Thread-Topic: Question on bfd.LocalDiag variable Thread-Index: Ac7E77k1jVFe9+R8TTm+TXwkxzirxQAAMPmw Date: Wed, 9 Oct 2013 13:07:35 +0000 Message-ID: <1F9891E667D15145880DF7BA13F037BF1C1784E2@ILPTWPVEXMB01.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.132.230] Content-Type: multipart/alternative; boundary="_000_1F9891E667D15145880DF7BA13F037BF1C1784E2ILPTWPVEXMB01ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPJsWRmVeSWpSXmKPExsUy+dWnL7oSoaFBBs+XGVt8/rON0YHRY8mS n0wBjFENjDaJeXn5JYklqQopqcXJtkoBRZllicmVSgqZKbZKhkoKBTmJyam5qXkltkqJBQWp eSlKdlwKGMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMlOTdnQ2JorJCOzWCFVNzcxM0ch N7W4ODE9VQEokrCFOePWw072gsYZjBVNz3exNTD2tzF2MXJySAiYSLy+0s8MYYtJXLi3nq2L kYtDSOAgo8S2ud1QzhFGiR29B9hAqtgEDCXWdG5kBbFFBDQl1s7ZDmYLC+hIzJ37gRkibigx bepWKNtIYtb1CywgNouAisS/lX1MIDavQIBE//ILYDWMQJu/n1oDFmcWEJe49WQ+E8RFAhJL 9pyHuk5U4uXjf6wQtrLE7OMPGSHq8yUeH73DCDFTUOLkzCcsEDWSEgdX3GCZwCg8C8nYWUha ZiFpgYjrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRTNzCkqSctMNDPVSkzNLUnNS9ZLz czcxQhLE8x2Mv+arHGIU4GBU4uHt4A0JEmJNLCuuzD3EKMnBpCTKez8gNEiILyk/pTIjsTgj vqg0J7X4EKMEB7OSCK+vBVCONyWxsiq1KB8mFQQMwYnMUtzJ+cCkl1cSb2xgQCRHSZx3eUO4 v5BAOjAVZqemFqQWwQyV4eBQkuBlDAHaJ1iUmp5akZaZU4KQZuLgBLmJB+gmdZAa3uKCxNzi zHSI/ClGRSlx3u/BQAkBkERGaR5cLyxfvGIUB4aAMK8QSDsPMNfAdb8CGswENHj79xCQwcAc ApeSamC8VSb+favZwfLEe/tWH3m9WMbmWbfWja3VAf55e97+2rDuhamMnMfWFft/zIvRFrjj x7K/9uTFlkmRUnerbwmc5TzSeDZ4xcdzT94W26VnPAm+MmPfx7qig6p3gpxflK9nEf41we3Q fIV5s7rfv+e3z488t+npzBnvsxiNp6h8YJ69PUL0vtssVyWW4oxEQy3mouJEAE/6dgryAwAA X-Mailman-Approved-At: Wed, 09 Oct 2013 06:28:04 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 13:07:48 -0000 --_000_1F9891E667D15145880DF7BA13F037BF1C1784E2ILPTWPVEXMB01ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear colleague, I have a question regarding the role of Diagnostic Code state variable in BF= D protocol. Section 6.8.1 "State Variables" says: bfd.LocalDiag The diagnostic code specifying the reason for the most recent change in the local session state. This MUST be initialized to zero (No Diagnostic).<<--- The "most recent change" is explicitly ment= ioned here Section 6.8.4 "Calculating the Detection Time" says" If Demand mode is not active, and a period of time equal to the Detection Time passes without receiving a BFD Control packet from the remote system, and bfd.SessionState is Init or Up, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 1 (Control Detection Time Expired). <<--- Change in bf= d.LocalDiag Section 6.8.6 "Reception of BFD Control Packets" says: If bfd.SessionState is AdminDown Discard the packet If received state is AdminDown If bfd.SessionState is not Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down Else If bfd.SessionState is Down If received State is Down Set bfd.SessionState to Init <<--- No change in bfd.LocalD= iag Else if received State is Init Set bfd.SessionState to Up <<--- No change in bfd.LocalDia= g Else if bfd.SessionState is Init If received State is Init or Up Set bfd.SessionState to Up <<--- No change in bfd.LocalDia= g Else (bfd.SessionState is Up) If received State is Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) <<= --- Change in bfd.LocalDiag Set bfd.SessionState to Down I.e.: * If the session goes Down-->Init-->Up immediately after creation, b= fd.LocalDiag would be 0 (because it has been initialized to 0 and not change= d after that) * But if the session that has been Up goes Up -->Down for any reason= and then recovers Down-->Init-->Up the value of bfd.localDiag that has spec= ified the reason for the last going Up-->Down will be preserved. We would like to know if bfd.LocalDiag value should be set for each session= state transition or only for state transition from Up/Init to Down? Regards, Evgeny Sandler System Engineer Network Solutions Division ECI Telecom Tel: +972-3-9266031 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_1F9891E667D15145880DF7BA13F037BF1C1784E2ILPTWPVEXMB01ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dear colleague,

 

I have a question regar= ding the role of Diagnostic Code state variable in BFD protocol.

 

Section 6.8.1 "Sta= te Variables" says:

 

  =   bfd.LocalDiag

 <= /o:p>

  =     The diagnostic code specifying the reason for the most re= cent

  =     change in the local session state.  This MUST be ini= tialized to

  =     zero (No Diagnostic).= <<--- The “most recent change” is explicitly mentioned her= e

 =

Section 6.8= .4 "Calculating the Detection Time" says"

 =

   = ; If Demand mode is not active, and a period of time equal to the<= /o:p>

   = ; Detection Time passes without receiving a BFD Control packet from the=

  =  remote system, and bfd.SessionState is Init or Up, the session has

  =  gone down -- the local system MUST set bfd.SessionState to Down and

  =  bfd.LocalDiag to 1 (Control Detection Time Expired).   <<--- Change in= bfd.LocalDiag

 

Section 6.8= .6 "Reception of BFD Control Packets" says:

 = 

    If bfd.SessionState is AdminDown
 
          Discard the=
 packet
 
      If received state is AdminDown<=
/o:p>
          If bfd.Sessi=
onState is not Down
           &=
nbsp;  Set bfd.LocalDiag to 3 (Neighbor signaled

           &=
nbsp;      session down)


           &=
nbsp;  Set bfd.SessionState to Down


 


      Else


 


          If bfd.Sessi=
onState is Down


           &=
nbsp;  If received State is Down


           &=
nbsp;      Set bfd.SessionState to Init <<--- No change in bfd.Loc=
alDiag


           &=
nbsp;  Else if received State is Init


           &=
nbsp;      Set bfd.SessionState to Up <<--- No change in bfd.Loc=
alDiag


 


          Else if bfd.=
SessionState is Init


           &=
nbsp;  If received State is Init or Up


           &=
nbsp;      Set bfd.SessionState to Up <<--- No change in bfd.Loc=
alDiag


 


          Else (bfd.Se=
ssionState is Up)


           &=
nbsp;  If received State is Down


           &=
nbsp;      Set bfd.LocalDiag to 3 (Neighbor signale=
d session down) <&=
lt;--- Change in bfd.LocalDiag


 &n=
bsp;            =
    Set bfd.SessionState to Down


 


I.e.:<=
/o:p>


·       &=
nbsp;
If the session goes Down-->Init-->Up immediately=
 after creation, bfd.LocalDiag would be 0 (because it has been initialized t=
o 0 and not changed after that)


·       &=
nbsp;
But if the session that has been Up goes Up -->Down=
 for any reason and then recovers Down-->Init-->Up the value of bfd.lo=
calDiag that has specified the reason for the
 last going Up-->Down will be preserved.


 =



We would li=
ke to know if bfd.LocalDiag value should be set for each session state trans=
ition or only for state transition from Up/Init to Down?

 =



Regards,


 


Evgeny Sandler


System Engineer


Network Solutions Divis=
ion


ECI Telecom<=
/span>


Tel: +972-3-9266031=



 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_1F9891E667D15145880DF7BA13F037BF1C1784E2ILPTWPVEXMB01ec_-- From dkatz@juniper.net Wed Oct 9 10:17:53 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EB321E805F for ; Wed, 9 Oct 2013 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g264JUVa-pf1 for ; Wed, 9 Oct 2013 10:17:47 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6171221E808C for ; Wed, 9 Oct 2013 10:17:44 -0700 (PDT) Received: from mail23-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 17:17:43 +0000 Received: from mail23-co1 (localhost [127.0.0.1]) by mail23-co1-R.bigfish.com (Postfix) with ESMTP id B0BE9C001DF for ; Wed, 9 Oct 2013 17:17:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz98dI9371Ic85eh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097h8275bhz2fh2a8h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2bh1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1e64h1fe8h1ff5h2052h20f0h20b3m1155h) Received-SPF: pass (mail23-co1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=dkatz@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail23-co1 (localhost.localdomain [127.0.0.1]) by mail23-co1 (MessageSwitch) id 138133899567310_21767; Wed, 9 Oct 2013 17:16:35 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.233]) by mail23-co1.bigfish.com (Postfix) with ESMTP id 763F98000B3; Wed, 9 Oct 2013 17:16:34 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 17:16:34 +0000 Received: from dkatz-sslvpn-nc.jnpr.net (172.23.11.115) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 10:16:32 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_7913C7DB-21A6-4F08-9621-AF262FC9BDCB" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Question on bfd.LocalDiag variable From: Dave Katz In-Reply-To: <1F9891E667D15145880DF7BA13F037BF1C1784E2@ILPTWPVEXMB01.ecitele.com> Date: Wed, 9 Oct 2013 10:16:31 -0700 Message-ID: <781143AC-7C03-4DD6-89A7-19653763A3E7@juniper.net> References: <1F9891E667D15145880DF7BA13F037BF1C1784E2@ILPTWPVEXMB01.ecitele.com> To: Evgeny Sandler X-Mailer: Apple Mail (2.1510) X-FOPE-CRA-Verdict: 66.129.224.54$ecitele.com%0%1%juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ECITELE.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 17:17:53 -0000 --Apple-Mail=_7913C7DB-21A6-4F08-9621-AF262FC9BDCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" The intent was to record the reason for the last session failure (the = Up->Down transition) and preserve it so there is a bit of state = available in the protocol--since the protocol is inherently unreliable = (running over UDP), repeatedly sending the diagnostic provides a crude = form of reliability for it. =20 The description of the field is, well, underspecified. Note also: This section discusses the normative requirements of the protocol in order to achieve interoperability. It is important for implementors to enforce only the requirements specified in this section, as misguided pedantry has been proven by experience to affect interoperability adversely. In other words, it's best to not do what's not in the spec=85 --Dave On Oct 9, 2013, at 6:07 AM, Evgeny Sandler = wrote: > Dear colleague, > =20 > I have a question regarding the role of Diagnostic Code state variable = in BFD protocol. > =20 > Section 6.8.1 "State Variables" says: > =20 > bfd.LocalDiag > =20 > The diagnostic code specifying the reason for the most recent > change in the local session state. This MUST be initialized to > zero (No Diagnostic).<<--- The =93most recent change=94 is = explicitly mentioned here > =20 > Section 6.8.4 "Calculating the Detection Time" says" > =20 > If Demand mode is not active, and a period of time equal to the > Detection Time passes without receiving a BFD Control packet from = the > remote system, and bfd.SessionState is Init or Up, the session has > gone down -- the local system MUST set bfd.SessionState to Down and > bfd.LocalDiag to 1 (Control Detection Time Expired). <<--- Change = in bfd.LocalDiag > =20 > Section 6.8.6 "Reception of BFD Control Packets" says: > =20 > If bfd.SessionState is AdminDown > =20 > Discard the packet > =20 > If received state is AdminDown > If bfd.SessionState is not Down > Set bfd.LocalDiag to 3 (Neighbor signaled > session down) > Set bfd.SessionState to Down > =20 > Else > =20 > If bfd.SessionState is Down > If received State is Down > Set bfd.SessionState to Init <<--- No change in = bfd.LocalDiag > Else if received State is Init > Set bfd.SessionState to Up <<--- No change in = bfd.LocalDiag > =20 > Else if bfd.SessionState is Init > If received State is Init or Up > Set bfd.SessionState to Up <<--- No change in = bfd.LocalDiag > =20 > Else (bfd.SessionState is Up) > If received State is Down > Set bfd.LocalDiag to 3 (Neighbor signaled session = down) <<--- Change in bfd.LocalDiag > Set bfd.SessionState to Down > =20 > I.e.: > =B7 If the session goes Down-->Init-->Up immediately after = creation, bfd.LocalDiag would be 0 (because it has been initialized to 0 = and not changed after that) > =B7 But if the session that has been Up goes Up -->Down for = any reason and then recovers Down-->Init-->Up the value of bfd.localDiag = that has specified the reason for the last going Up-->Down will be = preserved. > =20 > We would like to know if bfd.LocalDiag value should be set for each = session state transition or only for state transition from Up/Init to = Down? > =20 > Regards, > =20 > Evgeny Sandler > System Engineer > Network Solutions Division > ECI Telecom > Tel: +972-3-9266031 > =20 > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >=20 --Apple-Mail=_7913C7DB-21A6-4F08-9621-AF262FC9BDCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" The = intent was to record the reason for the last session failure (the = Up->Down transition) and preserve it so there is a bit of state = available in the protocol--since the protocol is inherently unreliable = (running over UDP), repeatedly sending the diagnostic provides a crude = form of reliability for it.  

The description of = the field is, well, underspecified.

Note = also:

  =
 This section discusses the normative requirements of the protocol in
   order to achieve interoperability.  It is important for implementors
   to enforce only the requirements specified in this section, as
   misguided pedantry has been proven by experience to affect
   interoperability adversely.

In other words, it's best to not do what's not = in the = spec=85

--Dave

On = Oct 9, 2013, at 6:07 AM, Evgeny Sandler <Evgeny.Sandler@ecitele.com&= gt; wrote:

Dear = colleague,
 
I have = a question regarding the role of Diagnostic Code state variable in BFD = protocol.
 
Section 6.8.1 "State Variables" = says:
 
    = bfd.LocalDiag
 
      The = diagnostic code specifying the reason for the most = recent
      change in the local = session state.  This MUST be initialized = to
      zero (No = Diagnostic).<<--- = The =93most recent change=94 is explicitly mentioned = here
 
Section 6.8.4 "Calculating the Detection Time" = says"
 
  =   If Demand mode is not active, and a period of time equal to = the
    Detection Time passes without = receiving a BFD Control packet from the
   gone down -- the local = system MUST set bfd.SessionState to Down and
 <<--- Change in = bfd.LocalDiag
 
Section 6.8.6 "Reception of BFD Control Packets" = says:
 
    If bfd.SessionState is =
AdminDown
 
 
      If received =
state is AdminDown
 
 
<<--- No change in =
bfd.LocalDiag
<<--- No change in =
bfd.LocalDiag
<<--- No change in =
bfd.LocalDiag
<<--- Change in =
bfd.LocalDiag
 
=B7 =B7  
We would like to know if bfd.LocalDiag value should be set for = each session state transition or only for state transition from Up/Init = to Down?
 
Regards,
Evgeny Sandler
System = Engineer
Network Solutions = Division
ECI Telecom
Tel: = +972-3-9266031
X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 03:07:41 -0000 --_89A90639-B9D8-4EC0-9829-D7EDCA5D4C5F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Failures recognized by BFD are communicated to peers through diagnostic cod= es, and not meant for all state transitions. And IMU, diagnostic codes refl= ect failure conditions. Regards, Binny. ---------- Aricent Group, India. Sent from Nokia Lumia. -----Original Message----- From: "Dave Katz" Sent: =E2=80=8E09-=E2=80=8E10-=E2=80=8E2013 10:47 PM To: "Evgeny Sandler" Cc: "rtg-bfd@ietf.org" Subject: Re: Question on bfd.LocalDiag variable The intent was to record the reason for the last session failure (the Up->D= own transition) and preserve it so there is a bit of state available in the= protocol--since the protocol is inherently unreliable (running over UDP), = repeatedly sending the diagnostic provides a crude form of reliability for = it. =20 The description of the field is, well, underspecified. Note also: This section discusses the normative requirements of the protocol in order to achieve interoperability. It is important for implementors to enforce only the requirements specified in this section, as misguided pedantry has been proven by experience to affect interoperability adversely. In other words, it's best to not do what's not in the spec=E2=80=A6 --Dave On Oct 9, 2013, at 6:07 AM, Evgeny Sandler wro= te: Dear colleague, =20 I have a question regarding the role of Diagnostic Code state variable in B= FD protocol. =20 Section 6.8.1 "State Variables" says: =20 bfd.LocalDiag =20 The diagnostic code specifying the reason for the most recent change in the local session state. This MUST be initialized to zero (No Diagnostic).<<--- The =E2=80=9Cmost recent change=E2=80=9D i= s explicitly mentioned here =20 Section 6.8.4 "Calculating the Detection Time" says" =20 If Demand mode is not active, and a period of time equal to the Detection Time passes without receiving a BFD Control packet from the remote system, and bfd.SessionState is Init or Up, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 1 (Control Detection Time Expired). <<--- Change in b= fd.LocalDiag =20 Section 6.8.6 "Reception of BFD Control Packets" says: =20 If bfd.SessionState is AdminDown Discard the packet If = received state is AdminDown If bfd.SessionState is not Down = Set bfd.LocalDiag to 3 (Neighbor signaled session d= own) Set bfd.SessionState to Down Else If bfd.= SessionState is Down If received State is Down = Set bfd.SessionState to Init <<--- No change in bfd.LocalDiag = Else if received State is Init Set bfd.SessionState to U= p <<--- No change in bfd.LocalDiag Else if bfd.SessionState is In= it If received State is Init or Up Set bfd.Se= ssionState to Up <<--- No change in bfd.LocalDiag Else (bfd.Sessi= onState is Up) If received State is Down Set = bfd.LocalDiag to 3 (Neighbor signaled session down) <<--- Change in bfd.Loc= alDiag Set bfd.SessionState to Down =20 I.e.: =C2=B7 If the session goes Down-->Init-->Up immediately after creat= ion, bfd.LocalDiag would be 0 (because it has been initialized to 0 and not= changed after that) =C2=B7 But if the session that has been Up goes Up -->Down for any = reason and then recovers Down-->Init-->Up the value of bfd.localDiag that h= as specified the reason for the last going Up-->Down will be preserved. =20 We would like to know if bfd.LocalDiag value should be set for each session= state transition or only for state transition from Up/Init to Down? =20 Regards, =20 Evgeny Sandler System Engineer Network Solutions Division ECI Telecom Tel: +972-3-9266031 =20 This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.= --_89A90639-B9D8-4EC0-9829-D7EDCA5D4C5F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Failures re= cognized by BFD are communicated to peers through diagnostic codes, and not= meant for all state transitions. And IMU, diagnostic codes reflect failure= conditions.

Regards,
Binny.
----------
Aricent Group, Indi= a.

Sent from Nokia Lumia.
From: Dave Katz
Sent: =E2=80=8E09-=E2=80=8E10-=E2=80=8E2013 10:47 PM
To: Evgeny SandlerCc: rtg-bfd@ietf.org=
Subject: Re: Question on bfd.LocalDiag variable

The intent was to record the reason for the last session failure (the Up= ->Down transition) and preserve it so there is a bit of state available = in the protocol--since the protocol is inherently unreliable (running over = UDP), repeatedly sending the diagnostic provides a crude form of reliabilit= y for it.  =20

The description of the field is, well, underspecified.=20

Note also:

   This section discusses the norma=
tive requirements of the protocol in
   order to achieve interoperability.  It is important for implementors
   to enforce only the requirements specified in this section, as
   misguided pedantry has been proven by experience to affect
   interoperability adversely.

In other words, it's best to not do what's not in the spec=E2=80=A6

--Dave

On Oct 9, 2013, at 6:07 AM, Evgeny Sandler <Evgeny.Sandler@ecitele.com> wrote:

Dear colleague,=
 
I have a question regardin= g the role of Diagnostic Code state variable in BFD protocol.
 
Section 6.8.1 "State Varia= bles" says:
 
    bfd.LocalDiag
 
      The diagnos= tic code specifying the reason for the most recent
      change in t= he local session state.  This MUST be initialized to=
      zero (No Di= agnostic).<<--- The =E2= =80=9Cmost recent change=E2=80=9D is explicitly mentioned here
 
Section 6.8.4 "C= alculating the Detection Time" says"
 
    If Demand mode is not a= ctive, and a period of time equal to the
    Detection Time passes w= ithout receiving a BFD Control packet from the
   remote system, and bfd.S= essionState is Init or Up, the session has
   gone down -- the local s= ystem MUST set bfd.SessionState to Down and
   bfd.LocalDiag to 1 (Cont= rol Detection Time Expired).   <<--- Change i= n bfd.LocalDiag
 
Section 6.8.6 "R= eception of BFD Control Packets" says:
 
 
         =
 Discard the packet
=
 
  &nb=
sp;   If received state is AdminDown
 =
         If bfd.SessionState is not=
 Down
        =
;      Set bfd.LocalDiag to 3 (Neighbor signaled
         =
         session down)
           =
;   Set bfd.SessionState to Down
 
      Else
 
          If bfd.Sess=
ionState is Down
      =
        If received State is Down
          =
;        Set bfd.SessionState to Init <<--- No change in bfd.LocalDi=
ag
       &=
nbsp;      Else if received State is Init
          &=
nbsp;       Set bfd.SessionState to Up <<--- No change in bfd.LocalDiag
 
     =
;     Else if bfd.SessionState is Init
           &nb=
sp;  If received State is Init or Up
  =
;            &n=
bsp;   Set bfd.SessionState to Up <<--- No change in bfd.LocalDiag
 
         =
 Else (bfd.SessionState is Up)
   &nbs=
p;          If received State =
is Down
       &=
nbsp;          Set bfd.LocalDi=
ag to 3 (Neighbor signaled session down) <<--- Change in bfd.LocalDiag


   &nbs=
p;            &=
nbsp; Set bfd.SessionState to Down


 


I.e.:=



=C2=B7         If the session goes Down-=
->Init-->Up immediately after creation, bfd.LocalDiag would be 0 (bec=
ause it has been initialized to 0 and not changed after that)


=C2=B7         But if the session that h=
as been Up goes Up -->Down for any reason and then recovers Down-->In=
it-->Up the value of bfd.localDiag that has specified the reason for the=
 last going Up-->Down will be preserved.


 

We would like to=
 know if bfd.LocalDiag value should be set for each session state transitio=
n or only for state transition from Up/Init to Down?

 

Regards,


 


Evgeny Sandler<=
/SPAN>


System Engineer=



Network Solutions Division=



ECI Telecom


Tel: +972-3-9266031


 


This e-mail message is intended for the recipient only and contains info=
rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. =
If you have received this transmission in error, please inform us by e-mail=
, phone or fax, and then delete the original and all copies thereof.

= --_89A90639-B9D8-4EC0-9829-D7EDCA5D4C5F_-- From jhaas@slice.pfrc.org Mon Oct 14 10:20:41 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9547121E8179 for ; Mon, 14 Oct 2013 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_39=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSFLLRYRWwDP for ; Mon, 14 Oct 2013 10:20:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9678F21F9E6C for ; Mon, 14 Oct 2013 10:20:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7E01BC259; Mon, 14 Oct 2013 13:20:35 -0400 (EDT) Date: Mon, 14 Oct 2013 13:20:35 -0400 From: Jeffrey Haas To: Binny Jeshan Subject: Re: Question on bfd.LocalDiag variable Message-ID: <20131014172035.GG17538@pfrc> References: <525619f9.43a3420a.0fa4.fffff2ad@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <525619f9.43a3420a.0fa4.fffff2ad@mx.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" , Dave Katz , Evgeny Sandler X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 17:20:41 -0000 On Thu, Oct 10, 2013 at 08:37:07AM +0530, Binny Jeshan wrote: > Failures recognized by BFD are communicated to peers through diagnostic codes, and not meant for all state transitions. And IMU, diagnostic codes reflect failure conditions. And has been commmented upon elsewhere, the diag code may be very short lived in some circumstances. Doing anything with it beyond using it for user diagnostic feedback is ill-advised. -- Jeff From internet-drafts@ietf.org Tue Oct 15 01:49:00 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AECA21F9F19; Tue, 15 Oct 2013 01:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drTsOryhuRVW; Tue, 15 Oct 2013 01:48:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C1611E8162; Tue, 15 Oct 2013 01:48:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-generic-crypto-auth-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015084855.2118.75761.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 01:48:55 -0700 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:49:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Generic Cryptographic Authentication Author(s) : Manav Bhatia Vishwas Manral Dacheng Zhang Filename : draft-ietf-bfd-generic-crypto-auth-05.txt Pages : 12 Date : 2013-10-15 Abstract: This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of arbitary cryptographic authentication algorithms in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure that is required for supporting algorithm and key agility for BFD. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-generic-crypto-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-generic-crypto-auth-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Oct 15 01:49:01 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA2221F9F19; Tue, 15 Oct 2013 01:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoXgUfXiq6Yi; Tue, 15 Oct 2013 01:49:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9177311E817D; Tue, 15 Oct 2013 01:48:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-hmac-sha-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015084857.2100.635.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 01:48:57 -0700 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:49:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Authenticating BFD using HMAC-SHA-2 procedures Author(s) : Dacheng Zhang Manav Bhatia Vishwas Manral Filename : draft-ietf-bfd-hmac-sha-04.txt Pages : 9 Date : 2013-10-15 Abstract: This document describes the mechanism to authenticate Bidirectional Forwarding Detection (BFD) protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms. The described mechanism uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This document updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-hmac-sha There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-hmac-sha-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobo@cisco.com Tue Oct 22 13:05:43 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3680311E824D for ; Tue, 22 Oct 2013 13:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiuhB-RPbPow for ; Tue, 22 Oct 2013 13:05:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DE9BB11E824A for ; Tue, 22 Oct 2013 13:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3162; q=dns/txt; s=iport; t=1382472338; x=1383681938; h=from:to:subject:date:message-id:mime-version; bh=NVCfK5MWWn6nHFFfYWTgqMSd5pz/YgQ64uzJP5GFYHs=; b=bh4j+FdZSI39vrIAzj/NECkJbbV7I/FEUIYbP1qh3UZucm4STNZOAlAi BQnmfvR06hTsNFUwoyM/NH77DOTuzyJE+FB0Uxa3psyBLEMOb4xy4Bg3b faHEHReMnYm0/BjRBCCLn3qLWoIECPXdsNaU/pH5I0VN7nmrF1+oIWWUp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcGAPzZZlKtJV2Y/2dsb2JhbABZgkMjIThUvkqBKxZtB4InAQQtXgEMHlYmAQQbAYd9AQyZMqFTjx2DV4EKA6oQgySCKg X-IronPort-AV: E=Sophos;i="4.93,550,1378857600"; d="scan'208,217";a="275264275" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2013 20:05:25 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MK5PZR012687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Oct 2013 20:05:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 15:05:24 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: IETF 88 BFD WG Agenda Thread-Topic: IETF 88 BFD WG Agenda Thread-Index: Ac7PYRMLS4xC1T4FS4SOi8J7m4y3sA== Date: Tue, 22 Oct 2013 20:05:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DE80F33xmbalnx01ciscoc_" MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:05:43 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DE80F33xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear BFD WG Members, IETF 88 draft BFD WG agenda has been published. http://www.ietf.org/proceedings/88/agenda/agenda-88-bfd Slides will be uploaded no later than Nov. 1st. -Nobo for the WG Chairs --_000_CECE764681BE964CBE1DFF78F3CDD3941DE80F33xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear BFD WG Members,

 

IETF 88 draft BFD WG agenda has been published.=

 

http://www.ietf.org/proceedings/88/agenda/agenda-88-bfd=

 

Slides will be uploaded no later than Nov. 1st<= /sup>.

 

-Nobo

for the WG Chairs

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941DE80F33xmbalnx01ciscoc_-- From venggovi@cisco.com Wed Oct 23 09:36:08 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E867411E83E2 for ; Wed, 23 Oct 2013 09:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSCquAJ+vURV for ; Wed, 23 Oct 2013 09:36:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 478F111E844C for ; Wed, 23 Oct 2013 09:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2328; q=dns/txt; s=iport; t=1382546149; x=1383755749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AroK12/Nqr184FDta6M3OEDo6l8h2YCufHa21yJqh5E=; b=AwXBmDZMWwsOjZApfCHQAnrwRHFKxfpZW/I/+gMfZOgq2j8OcbQJB9vf L3E8h37w4LZbjusZqYXcHSft3zkyY0C+j02wZBstyVmohNYYxTSNkYisd NW12Jy868v1otRTO36tN1YXPTutE0QRZhQFeCCMRKIYo8jLrk017QtIDy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0GAHf6Z1KtJXG+/2dsb2JhbABZgwc4VIMquyIYgRYWbQeCJQEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEDgUIAYd9DagsklSBKY10MQcGgmQ1gQsDmTiQWIMkgio X-IronPort-AV: E=Sophos;i="4.93,555,1378857600"; d="scan'208";a="275712491" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 23 Oct 2013 16:35:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9NGZmq0026596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 16:35:48 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 11:35:48 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-00.txt Thread-Topic: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-00.txt Thread-Index: AQHOzNGDab5V6xC0bU6gMxg6QMQM4JoCf0Ag Date: Wed, 23 Oct 2013 16:35:48 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D337E7816@xmb-rcd-x15.cisco.com> References: <20131019134540.9578.9674.idtracker@ietfa.amsl.com> In-Reply-To: <20131019134540.9578.9674.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 16:36:08 -0000 SGVsbG8gYWxsLA0KICBUaGUgZm9sbG93aW5nIGRyYWZ0IG1heSBiZSBvZiBpbnRlcmVzdCB0byB0 aGUgbWVtYmVycyBvZiB0aGUgQkZEIFdHIGFzIHdlbGwuIA0KVGhhbmtzDQpQcmFzYWQNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTYXR1cmRheSwgT2N0b2Jl ciAxOSwgMjAxMyA3OjE2IFBNDQpUbzogU2FtZXIgU2FsYW0gKHNzYWxhbSk7IEFsaSBTYWphc3Np IChzYWphc3NpKTsgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKQ0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1i ZmQtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZnb3ZpbmRhbi1sMnZw bi1ldnBuLWJmZC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVmVu Z2FkYSBQcmFzYWQgR292aW5kYW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpGaWxlbmFtZToJIGRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZA0KUmV2aXNpb246CSAw MA0KVGl0bGU6CQkgUHJvYWN0aXZlIGZhdWx0IGRldGVjdGlvbiBpbiBFLVZQTg0KQ3JlYXRpb24g ZGF0ZToJIDIwMTMtMTAtMTkNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVy IG9mIHBhZ2VzOiA4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0wMC50eHQNClN0YXR1czog ICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12Z292aW5kYW4t bDJ2cG4tZXZwbi1iZmQNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZkLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBU aGlzIGRvY3VtZW50IHByb3Bvc2VzIGEgcHJvYWN0aXZlLCBpbi1iYW5kIG5ldHdvcmsgT0FNIG1l Y2hhbmlzbSB0bw0KICAgZGV0ZWN0IGNvbm5lY3Rpdml0eSBmYXVsdHMgdGhhdCBhZmZlY3QgdW5p Y2FzdCBhbmQgbXVsdGktZGVzdGluYXRpb24NCiAgIHBhdGhzIGluIGFuIEUtVlBOIG5ldHdvcmsu IFRoZSBtdWx0aS1kZXN0aW5hdGlvbiBwYXRocyBhcmUgdXNlZCBieQ0KICAgQnJvYWRjYXN0LCB1 bmtub3duIFVuaWNhc3QgYW5kIE11bHRpY2FzdCAoQlVNKSB0cmFmZmljLiBUaGUNCiAgIG1lY2hh bmlzbXMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0IHVzZSB0aGUgcHJpbmNpcGxlcyBvZiB0aGUgd2lk ZWx5DQogICBhZG9wdGVkIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkg cHJvdG9jb2wuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobo@cisco.com Wed Oct 23 10:06:54 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115B711E8470 for ; Wed, 23 Oct 2013 10:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNaFK2BfHeDx for ; Wed, 23 Oct 2013 10:06:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA0511E83FF for ; Wed, 23 Oct 2013 10:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2818; q=dns/txt; s=iport; t=1382547998; x=1383757598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LrPIpNu1vNv2fTS2OaVpc+kiTORg9jMdUK1awFSfQfg=; b=mWF3/XMhAQNsNORLLOvbWE+L1LF+W8hwAvCYLFcc4Fno41cwTYwZkWd8 WI2w900j5+tggtzRca4dy4+yYa+H9m+jlRrlx7ynhxsNWt8fs0QxJtW0v tZK1xAEYYHqk40lhT63Ae02zrOcFEIXXeoaT/0gsfVaKt+sVyDwXtlDMX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJUBaFKtJV2Y/2dsb2JhbABZgmYhOFSDKrslGIEWFnSCJQEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEICAIEAQ0FCAGHfQEMqC6SUYEpjXQWGwcGgmQ1gQsDmTiQWIMkgio X-IronPort-AV: E=Sophos;i="4.93,555,1378857600"; d="scan'208";a="275741695" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2013 17:06:36 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9NH6aih030233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 17:06:36 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 12:06:35 -0500 From: "Nobo Akiya (nobo)" To: "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-00.txt Thread-Topic: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-00.txt Thread-Index: AQHOzNGDab5V6xC0bU6gMxg6QMQM4JoCf0AggAALRxA= Date: Wed, 23 Oct 2013 17:06:35 +0000 Message-ID: References: <20131019134540.9578.9674.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D337E7816@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D337E7816@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 17:06:54 -0000 RllJLA0KDQpEcmFmdCB3aWxsIGJlIHByZXNlbnRlZCBpbiBMMlZQTiBXRyBhdCBJRVRGODguDQoN Ci1Ob2JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVmVuZ2FkYSBQ cmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjMs IDIwMTMgMTI6MzYgUE0NCj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gQ2M6IE5vYm8gQWtpeWEg KG5vYm8pOyBKZWZmcmV5IEhhYXMNCj4gU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZkLQ0KPiAwMC50eHQNCj4gDQo+ IEhlbGxvIGFsbCwNCj4gICBUaGUgZm9sbG93aW5nIGRyYWZ0IG1heSBiZSBvZiBpbnRlcmVzdCB0 byB0aGUgbWVtYmVycyBvZiB0aGUgQkZEIFdHIGFzDQo+IHdlbGwuDQo+IFRoYW5rcw0KPiBQcmFz YWQNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDog U2F0dXJkYXksIE9jdG9iZXIgMTksIDIwMTMgNzoxNiBQTQ0KPiBUbzogU2FtZXIgU2FsYW0gKHNz YWxhbSk7IEFsaSBTYWphc3NpIChzYWphc3NpKTsgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW4NCj4g KHZlbmdnb3ZpKQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0NCj4gMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0wMC50eHQNCj4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiBh bmQgcG9zdGVkIHRvDQo+IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRy YWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZA0KPiBSZXZpc2lvbjoJIDAwDQo+IFRpdGxlOgkJ IFByb2FjdGl2ZSBmYXVsdCBkZXRlY3Rpb24gaW4gRS1WUE4NCj4gQ3JlYXRpb24gZGF0ZToJIDIw MTMtMTAtMTkNCj4gR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBw YWdlczogOA0KPiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXZnb3ZpbmRhbi1sMnZwbi0NCj4gZXZwbi1iZmQtMDAudHh0DQo+IFN0YXR1 czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12Z292aW5k YW4tbDJ2cG4tZXZwbi1iZmQNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1iZmQtMDANCj4gDQo+IA0KPiBBYnN0 cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIHByb2FjdGl2ZSwgaW4tYmFuZCBu ZXR3b3JrIE9BTSBtZWNoYW5pc20gdG8NCj4gICAgZGV0ZWN0IGNvbm5lY3Rpdml0eSBmYXVsdHMg dGhhdCBhZmZlY3QgdW5pY2FzdCBhbmQgbXVsdGktZGVzdGluYXRpb24NCj4gICAgcGF0aHMgaW4g YW4gRS1WUE4gbmV0d29yay4gVGhlIG11bHRpLWRlc3RpbmF0aW9uIHBhdGhzIGFyZSB1c2VkIGJ5 DQo+ICAgIEJyb2FkY2FzdCwgdW5rbm93biBVbmljYXN0IGFuZCBNdWx0aWNhc3QgKEJVTSkgdHJh ZmZpYy4gVGhlDQo+ICAgIG1lY2hhbmlzbXMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0IHVzZSB0aGUg cHJpbmNpcGxlcyBvZiB0aGUgd2lkZWx5DQo+ICAgIGFkb3B0ZWQgQmlkaXJlY3Rpb25hbCBGb3J3 YXJkaW5nIERldGVjdGlvbiAoQkZEKSBwcm90b2NvbC4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From ietf-secretariat-reply@ietf.org Wed Oct 23 14:50:12 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5488C11E824F for ; Wed, 23 Oct 2013 14:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b27FwQU5nFfJ for ; Wed, 23 Oct 2013 14:50:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6E11E825B for ; Wed, 23 Oct 2013 14:50:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131023215009.27916.18300.idtracker@ietfa.amsl.com> Date: Wed, 23 Oct 2013 14:50:09 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 23 Oct 2013 14:51:13 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:50:12 -0000 Changed milestone "Submit the bootstrapping mechanism for BFD using DHCP to the IESG to be considered as a Proposed Standard", resolved as "Dropped". Changed milestone "Submit the BFD MIB to the IESG to be considered as a Proposed Standard", set due date to November 2013 from September 2011. Changed milestone "Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard", set due date to June 2014 from March 2012. Changed milestone "Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard", set due date to January 2015 from December 2011. Changed milestone "Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard", set due date to January 2015 from December 2011. Changed milestone "Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard", set due date to January 2015 from December 2011. URL: http://datatracker.ietf.org/wg/bfd/charter/ From ietf-secretariat-reply@ietf.org Wed Oct 23 14:55:22 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EDA11E81C7 for ; Wed, 23 Oct 2013 14:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr6QelrzWi-O for ; Wed, 23 Oct 2013 14:55:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5417811E821E for ; Wed, 23 Oct 2013 14:55:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131023215519.27942.89271.idtracker@ietfa.amsl.com> Date: Wed, 23 Oct 2013 14:55:19 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 23 Oct 2013 14:57:52 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:55:22 -0000 URL: http://datatracker.ietf.org/wg/bfd/charter/ From ietf-secretariat-reply@ietf.org Wed Oct 23 14:56:47 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FCE11E8265 for ; Wed, 23 Oct 2013 14:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XonqSBL-vRG for ; Wed, 23 Oct 2013 14:56:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ACB11E8272 for ; Wed, 23 Oct 2013 14:56:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131023215646.27994.4947.idtracker@ietfa.amsl.com> Date: Wed, 23 Oct 2013 14:56:46 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 23 Oct 2013 14:57:52 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:56:47 -0000 URL: http://datatracker.ietf.org/wg/bfd/charter/ From jhaas@slice.pfrc.org Wed Oct 23 14:59:36 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7D21F9F99 for ; Wed, 23 Oct 2013 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY5AlpFhpz9E for ; Wed, 23 Oct 2013 14:59:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4B221F9F51 for ; Wed, 23 Oct 2013 14:59:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F3705C3B1; Wed, 23 Oct 2013 17:59:30 -0400 (EDT) Date: Wed, 23 Oct 2013 17:59:30 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Milestones changed for bfd WG Message-ID: <20131023215930.GM17538@pfrc> References: <20131023215009.27916.18300.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131023215009.27916.18300.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 21:59:36 -0000 Just updating the milestones to match consensus on the list from a while ago. -- Jeff (for the chairs) On Wed, Oct 23, 2013 at 02:50:09PM -0700, IETF Secretariat wrote: > Changed milestone "Submit the bootstrapping mechanism for BFD using > DHCP to the IESG to be considered as a Proposed Standard", resolved as > "Dropped". > > Changed milestone "Submit the BFD MIB to the IESG to be considered as > a Proposed Standard", set due date to November 2013 from September > 2011. > > Changed milestone "Submit the the document on BFD point-to-multipoint > support to the IESG to be considered as a Proposed Standard", set due > date to June 2014 from March 2012. > > Changed milestone "Submit the generic keying based cryptographic > authentication mechanism to the IESG to be considered as a Proposed > Standard", set due date to January 2015 from December 2011. > > Changed milestone "Submit a BFD MIB extension in support of the > generic keying document to the IESG to be considered as a Proposed > Standard", set due date to January 2015 from December 2011. > > Changed milestone "Submit the cryptographic authentication procedures > for BFD to the IESG to be considered as a Proposed Standard", set due > date to January 2015 from December 2011. > > URL: http://datatracker.ietf.org/wg/bfd/charter/ From ietf-secretariat-reply@ietf.org Thu Oct 24 04:06:34 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275C211E8318 for ; Thu, 24 Oct 2013 04:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NatfLq7BmiNG for ; Thu, 24 Oct 2013 04:06:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4F711E82D5 for ; Thu, 24 Oct 2013 04:06:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131024110631.30906.68297.idtracker@ietfa.amsl.com> Date: Thu, 24 Oct 2013 04:06:31 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 24 Oct 2013 05:57:20 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 11:06:35 -0000 Changed milestone "Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/bfd/charter/ From ietf-secretariat-reply@ietf.org Thu Oct 24 08:17:16 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47A211E834E for ; Thu, 24 Oct 2013 08:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsJMp-MgqAnr for ; Thu, 24 Oct 2013 08:17:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 720A511E833C for ; Thu, 24 Oct 2013 08:17:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131024151716.2344.68051.idtracker@ietfa.amsl.com> Date: Thu, 24 Oct 2013 08:17:16 -0700 From: IETF Secretariat X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 15:17:17 -0000 Changed milestone "Submit the BFD MIB to the IESG to be considered as a Proposed Standard", added draft-ietf-bfd-mib, draft-ietf-bfd-tc-mib to milestone. Changed milestone "Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard", added draft-ietf-bfd-multipoint to milestone. Changed milestone "Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard", added draft-ietf-bfd-generic-crypto-auth to milestone. Changed milestone "Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard", added draft-ietf-bfd-hmac-sha to milestone. URL: http://datatracker.ietf.org/wg/bfd/charter/ From jhaas@slice.pfrc.org Thu Oct 24 12:06:20 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D18811E8182 for ; Thu, 24 Oct 2013 12:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao6vsnHYn0Qv for ; Thu, 24 Oct 2013 12:06:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4C23111E81F5 for ; Thu, 24 Oct 2013 12:06:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EE229C309; Thu, 24 Oct 2013 15:06:12 -0400 (EDT) Date: Thu, 24 Oct 2013 15:06:12 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: WGLC for BFD base MIB and TC - ends November 8 Message-ID: <20131024190612.GN17538@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 19:06:20 -0000 This email is to initiate working group last call on the BFD MIB and Textual-Convention documents: http://tools.ietf.org/html/draft-ietf-bfd-mib-14 http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 The last call will complete on November 8, the end of IETF week. Time will be available during the Vancouver IETF BFD session to discuss last call comments. I will be serving as document shepherd (RFC 4858) for this WGLC. Due to the small nature of the BFD working group and the fact that both working group chairs have contributed to the documents, we have gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an independent party to gauge working group consensus. In order to facilitate the transparency of this WGLC, please remember to send all comments to the working group mailing list. As is often the case with MIB documents, implementations typically do not exist for the final form of the document. Typically enterprise MIBs are implemented at some point in the document life cycle and then later the implementor will revise to match the published RFC, including OID code-points assigned by IANA. Reviewers examining the MIB against deployed implementations are requested to bear in mind implementability of the final document vs. existence proof of the running code. Finally, note that no IPR polling has been done for these documents. MIBs, being IETF data models of things that themselves may have IPR, tend not to have IPR against them. However, if someone is aware of IPR against these documents, please state it for the WG. -- Jeff (for the chairs) From jhaas@slice.pfrc.org Thu Oct 24 12:14:35 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2C11E8208 for ; Thu, 24 Oct 2013 12:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chKQ3zWjeFiS for ; Thu, 24 Oct 2013 12:14:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8052D11E81ED for ; Thu, 24 Oct 2013 12:14:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 50068C312; Thu, 24 Oct 2013 15:14:31 -0400 (EDT) Date: Thu, 24 Oct 2013 15:14:31 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Message-ID: <20131024191431.GO17538@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 19:14:35 -0000 This email is to initiate working group last call on the BFD on Link Aggregate Group Interfaces document: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 The last call will complete on November 8, the end of IETF week. Time will be available during the Vancouver IETF BFD session to discuss last call comments. Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. Due to the small nature of the BFD working group and the fact that both working group chairs have contributed to this document, we have gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an independent party to gauge working group consensus. In order to facilitate the transparency of this WGLC, please remember to send all comments to the working group mailing list. IPR declarations have been filed against this draft and the document authors and contributors have been polled for any further IPR. Current IPR declarations may be seen at the following link: http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-bfd-on-lags If you are aware of additional IPR against this document please declare so, per the IETF Note Well. Finally, the IEEE has expressed interest in the disposition of this draft. They will likely provide additional commentary, if any, via the IETF liaison process. This process will likely happen after WGLC concludes. Depending on their feedback, WGLC may re-open to address their concerns. -- Jeff (for the chairs) From wim.henderickx@alcatel-lucent.com Thu Oct 24 12:29:19 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B582611E8351 for ; Thu, 24 Oct 2013 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI7YI8vM8NsY for ; Thu, 24 Oct 2013 12:29:14 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3D25611E8156 for ; Thu, 24 Oct 2013 12:29:14 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9OJT8Zr017528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Oct 2013 14:29:10 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9OJT7T9007495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 21:29:08 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.193]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 24 Oct 2013 21:29:07 +0200 From: "Henderickx, Wim (Wim)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0O1M80Tu8oAhPE+i2xw2+/vu3JoEPLqA Date: Thu, 24 Oct 2013 19:29:07 +0000 Message-ID: In-Reply-To: <20131024191431.GO17538@pfrc> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <2B8B8C1A8B84704F8ED3A3EB7E739B46@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 19:29:19 -0000 support On 24/10/13 21:14, "Jeffrey Haas" wrote: >This email is to initiate working group last call on the BFD on Link >Aggregate Group Interfaces document: > >http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > >The last call will complete on November 8, the end of IETF week. Time >will >be available during the Vancouver IETF BFD session to discuss last call >comments. > >Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. > >Due to the small nature of the BFD working group and the fact that both >working group chairs have contributed to this document, we have gotten >Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an >independent party to gauge working group consensus. > >In order to facilitate the transparency of this WGLC, please remember to >send all comments to the working group mailing list. > >IPR declarations have been filed against this draft and the document >authors >and contributors have been polled for any further IPR. Current IPR >declarations may be seen at the following link: > >http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ie >tf-bfd-on-lags > >If you are aware of additional IPR against this document please declare >so, per >the IETF Note Well. > >Finally, the IEEE has expressed interest in the disposition of this draft. >They will likely provide additional commentary, if any, via the IETF >liaison >process. This process will likely happen after WGLC concludes. Depending >on their feedback, WGLC may re-open to address their concerns. > >-- Jeff (for the chairs) From jeff.tantsura@ericsson.com Thu Oct 24 12:50:49 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5B711E81DC for ; Thu, 24 Oct 2013 12:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iiwpWNY0RDU for ; Thu, 24 Oct 2013 12:50:44 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 336D111E81B8 for ; Thu, 24 Oct 2013 12:50:44 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-fb-52697a13e6bb Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 56.6E.09414.31A79625; Thu, 24 Oct 2013 21:50:43 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 15:50:43 -0400 From: Jeff Tantsura To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0PJSjqHoQ47yqk62s2PGdgQ2cQ== Date: Thu, 24 Oct 2013 19:50:41 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748399812D9@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXRPiK5wVWaQQdt+G4v9B9+yWnz+s43R gcljyZKfTB6Xe7eyBjBFcdmkpOZklqUW6dslcGX82zaFtWAPb8W7tqusDYzt3F2MHBwSAiYS C+/ZdjFyApliEhfurWfrYuTiEBI4yijxtLuPHcJZzihxvKeLCaSKTcBA4v+34ywgtoiAh0T3 seeMILawQJDEvRcXmSDiwRJLduyAqtGTeNazASzOIqAq8ebNd1YQm1fAW6Lp0GqwGk4Be4k5 v3+xgdiMQFd8P7UGrJ5ZQFzi1pP5TBDXCUgs2XOeGcIWlXj5+B/YHFGg+W3HzrBDxJUlvs95 xALRqyOxYPcnNgjbWmLJmw6ouLbEsoWvmSFuEJQ4OfMJywRGsVlI1s1C0j4LSfssJO2zkLQv YGRdxchRWpxalptuZLCJERg9xyTYdHcw7nlpeYhRmoNFSZz3y1vnICGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MXkpqraIXEpe7PzzrXi1SH3jjs8GtbZ4iEiYZH3hStf9Nyzot8yt2Qb7/ o0iNNxV/3qzmd0np32cc/NitXUH7HYdNZNR0zj7l0BVOi3iE9wcxZ71YW7n8IfdRo1I2+SeK d/wf1HiealTNq2520tc5JJuj5xv6RHPSfAaPk08yDLhX3Vl0eKISS3FGoqEWc1FxIgDCAhLc bAIAAA== X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 19:50:49 -0000 Yes/support Cheers, Jeff > >On 24/10/13 21:14, "Jeffrey Haas" wrote: > >>This email is to initiate working group last call on the BFD on Link >>Aggregate Group Interfaces document: >> >>http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >> >>The last call will complete on November 8, the end of IETF week. Time >>will >>be available during the Vancouver IETF BFD session to discuss last call >>comments. >> >>Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. >> >>Due to the small nature of the BFD working group and the fact that both >>working group chairs have contributed to this document, we have gotten >>Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an >>independent party to gauge working group consensus. >> >>In order to facilitate the transparency of this WGLC, please remember to >>send all comments to the working group mailing list. >> >>IPR declarations have been filed against this draft and the document >>authors >>and contributors have been polled for any further IPR. Current IPR >>declarations may be seen at the following link: >> >>http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft-i >>e >>tf-bfd-on-lags >> >>If you are aware of additional IPR against this document please declare >>so, per >>the IETF Note Well. >> >>Finally, the IEEE has expressed interest in the disposition of this >>draft. >>They will likely provide additional commentary, if any, via the IETF >>liaison >>process. This process will likely happen after WGLC concludes. >>Depending >>on their feedback, WGLC may re-open to address their concerns. >> >>-- Jeff (for the chairs) > From manav.bhatia@alcatel-lucent.com Thu Oct 24 17:49:02 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0645411E825B for ; Thu, 24 Oct 2013 17:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTTLqBd9gCAS for ; Thu, 24 Oct 2013 17:48:56 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4111E8122 for ; Thu, 24 Oct 2013 17:48:55 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9P0mrvP019683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Oct 2013 19:48:54 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r9P0mqqA012389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 20:48:53 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 24 Oct 2013 20:48:52 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 08:48:48 +0800 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0O1MQVaqT3J2N0WjlZNM+4CFRpoElgbQ Date: Fri, 25 Oct 2013 00:48:47 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4EBA7A@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20131024191431.GO17538@pfrc> In-Reply-To: <20131024191431.GO17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 00:49:02 -0000 Support. > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Friday, October 25, 2013 12:45 AM > To: rtg-bfd@ietf.org > Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends > November 8 >=20 > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >=20 > The last call will complete on November 8, the end of IETF week. Time > will be available during the Vancouver IETF BFD session to discuss last > call comments. >=20 > Nobo Akiya will be serving as document shepherd (RFC 4858) for this > WGLC. >=20 > Due to the small nature of the BFD working group and the fact that both > working group chairs have contributed to this document, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an > independent party to gauge working group consensus. >=20 > In order to facilitate the transparency of this WGLC, please remember > to send all comments to the working group mailing list. >=20 > IPR declarations have been filed against this draft and the document > authors and contributors have been polled for any further IPR. Current > IPR declarations may be seen at the following link: >=20 > http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft > -ietf-bfd-on-lags >=20 > If you are aware of additional IPR against this document please declare > so, per the IETF Note Well. >=20 > Finally, the IEEE has expressed interest in the disposition of this > draft. > They will likely provide additional commentary, if any, via the IETF > liaison process. This process will likely happen after WGLC concludes. > Depending on their feedback, WGLC may re-open to address their > concerns. >=20 > -- Jeff (for the chairs) From srihari@cisco.com Thu Oct 24 18:08:08 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C125F11E827F for ; Thu, 24 Oct 2013 18:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B3+MGfZ1Xmo for ; Thu, 24 Oct 2013 18:08:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E315C11E827D for ; Thu, 24 Oct 2013 18:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1670; q=dns/txt; s=iport; t=1382663281; x=1383872881; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=mjhpImnCBd5QpSxBAV11jQP+pDeF2Ulpu7i+3k1+obo=; b=YMG7A5XY8oVXoghu40F40BFUa8RLOMe477y34XIuffsPkhgNPA87ZTRr Mme409WkZAflFP+CZCCNf6fdncOqiSunI+fuo9lIxLbxEUIREhuxMJB0L N53h1y8uUgBpR0oBiywdNgH4GZB8XRn5nau7aCOjuFOJcHPb7GLhY75YA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANLDaVKtJV2a/2dsb2JhbABZgwc4VL5TgSIWdIInAQQ6NB0BCA4UFEIlAgQBEgiHfw26GI4EgRYCOIMfgQ0DlCqFD5BYgySBcTk X-IronPort-AV: E=Sophos;i="4.93,566,1378857600"; d="scan'208";a="276409611" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2013 01:07:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9P17veo003260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 01:07:57 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.88]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 20:07:57 -0500 From: "Srihari Raghavan (srihari)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0O1YTYwKkDSbbE6tYk38a5CaO5oFTGyA Date: Fri, 25 Oct 2013 01:07:56 +0000 Message-ID: <3AC6B50876817C4AAFBF414E8F6090F71EFD38B9@xmb-aln-x11.cisco.com> In-Reply-To: <20131024191431.GO17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <0077678EDFAA154FB7680707B1E1EEE0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 01:08:08 -0000 Yes/support. Thanks Srihari On 25/10/13 12:44 AM, "Jeffrey Haas" wrote: >This email is to initiate working group last call on the BFD on Link >Aggregate Group Interfaces document: > >http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > >The last call will complete on November 8, the end of IETF week. Time >will >be available during the Vancouver IETF BFD session to discuss last call >comments. > >Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. > >Due to the small nature of the BFD working group and the fact that both >working group chairs have contributed to this document, we have gotten >Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an >independent party to gauge working group consensus. > >In order to facilitate the transparency of this WGLC, please remember to >send all comments to the working group mailing list. > >IPR declarations have been filed against this draft and the document >authors >and contributors have been polled for any further IPR. Current IPR >declarations may be seen at the following link: > >http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ie >tf-bfd-on-lags > >If you are aware of additional IPR against this document please declare >so, per >the IETF Note Well. > >Finally, the IEEE has expressed interest in the disposition of this draft. >They will likely provide additional commentary, if any, via the IETF >liaison >process. This process will likely happen after WGLC concludes. Depending >on their feedback, WGLC may re-open to address their concerns. > >-- Jeff (for the chairs) From srihari@cisco.com Thu Oct 24 18:08:33 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C926811E8286 for ; Thu, 24 Oct 2013 18:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-ZgyNrP4tf5 for ; Thu, 24 Oct 2013 18:08:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CA8AA11E821E for ; Thu, 24 Oct 2013 18:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1768; q=dns/txt; s=iport; t=1382663305; x=1383872905; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=2ZSKiF5/ZfOD7MyoMv080HsZ04N5iAwHPVR+D2IxfR4=; b=CIlXnRjHmbLN72r+0DXVRDpJ+Q9iuTpO25B0iKRkoFiUcU+WS7xAQDft mq5KzF/RUDRS+fy65lfYVuvC+vWZJF9qTlxuLODGJdnlwjjJ9Pui9fDWZ ubYvTsgPRmA6AYym5glTDWFTkF6O6Ss06ShGs43LJ/WcklyVk4ONbdLpK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANLDaVKtJXG8/2dsb2JhbABZgwc4VL5TgSIWdIInAQQ6NB0BCA4UFEIlAgQBEggRh24NuhiOBIEYOIMfgQ0DlCqFD5BYgySBcTk X-IronPort-AV: E=Sophos;i="4.93,566,1378857600"; d="scan'208";a="276402170" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 25 Oct 2013 01:08:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9P18Drr019198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 01:08:13 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.88]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 20:08:13 -0500 From: "Srihari Raghavan (srihari)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO0Owjsm9dwnZtIkiFrzvST4bDrpoFTIMA Date: Fri, 25 Oct 2013 01:08:12 +0000 Message-ID: <3AC6B50876817C4AAFBF414E8F6090F71EFD38C3@xmb-aln-x11.cisco.com> In-Reply-To: <20131024190612.GN17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BB2EFD0753A3E42A8E4A03C1C215B17@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 01:08:34 -0000 Yes/Support. Thanks Srihari On 25/10/13 12:36 AM, "Jeffrey Haas" wrote: >This email is to initiate working group last call on the BFD MIB and >Textual-Convention documents: > >http://tools.ietf.org/html/draft-ietf-bfd-mib-14 >http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 > >The last call will complete on November 8, the end of IETF week. Time >will >be available during the Vancouver IETF BFD session to discuss last call >comments. > >I will be serving as document shepherd (RFC 4858) for this WGLC. > >Due to the small nature of the BFD working group and the fact that both >working group chairs have contributed to the documents, we have gotten >Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an >independent party to gauge working group consensus. > >In order to facilitate the transparency of this WGLC, please remember to >send all comments to the working group mailing list. > >As is often the case with MIB documents, implementations typically do not >exist for the final form of the document. Typically enterprise MIBs are >implemented at some point in the document life cycle and then later the >implementor will revise to match the published RFC, including OID >code-points assigned by IANA. Reviewers examining the MIB against >deployed >implementations are requested to bear in mind implementability of the >final >document vs. existence proof of the running code. > >Finally, note that no IPR polling has been done for these documents. >MIBs, >being IETF data models of things that themselves may have IPR, tend not to >have IPR against them. However, if someone is aware of IPR against these >documents, please state it for the WG. > >-- Jeff (for the chairs) From marc@sniff.de Thu Oct 24 18:40:11 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5457311E81A3 for ; Thu, 24 Oct 2013 18:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa-Y3AQXOv0r for ; Thu, 24 Oct 2013 18:40:10 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5E111E8288 for ; Thu, 24 Oct 2013 18:40:06 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id AB7442AA0F; Fri, 25 Oct 2013 01:40:04 +0000 (GMT) Date: Thu, 24 Oct 2013 18:40:04 -0700 From: Marc Binderberger To: Jeffrey Haas , "rtg-bfd@ietf.org" Message-ID: <20131024184004981067.74053924@sniff.de> In-Reply-To: <20131024191431.GO17538@pfrc> References: <20131024191431.GO17538@pfrc> Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 01:40:11 -0000 Support Marc On Thu, 24 Oct 2013 15:14:31 -0400, Jeffrey Haas wrote: > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > The last call will complete on November 8, the end of IETF week. Time will > be available during the Vancouver IETF BFD session to discuss last call > comments. > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. > > Due to the small nature of the BFD working group and the fact that both > working group chairs have contributed to this document, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an > independent party to gauge working group consensus. > > In order to facilitate the transparency of this WGLC, please remember to > send all comments to the working group mailing list. > > IPR declarations have been filed against this draft and the document authors > and contributors have been polled for any further IPR. Current IPR > declarations may be seen at the following link: > > http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-bfd-on-lags > > If you are aware of additional IPR against this document please > declare so, per > the IETF Note Well. > > Finally, the IEEE has expressed interest in the disposition of this draft. > They will likely provide additional commentary, if any, via the IETF liaison > process. This process will likely happen after WGLC concludes. Depending > on their feedback, WGLC may re-open to address their concerns. > > -- Jeff (for the chairs) > From shtsuchi@cisco.com Thu Oct 24 18:46:23 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2271F11E828D for ; Thu, 24 Oct 2013 18:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DV69KbmAuC9 for ; Thu, 24 Oct 2013 18:46:15 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id D079C11E8288 for ; Thu, 24 Oct 2013 18:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1669; q=dns/txt; s=iport; t=1382665574; x=1383875174; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=rOtFakWIvygXyzrkLHIMHKu8g+hNwX8IMjskOnZl+cw=; b=dylP1NiVbWsZS1AlrK2RJ+3vZqrBwLTaKAsn8zpyqNX7vVzkk75kl6WG ihG8WlNmCD3gMwvdkfEIOi06XQBw8moDa8cxHt6F9pqJjvIGcfBCNEzLg /W4JPRfgHi2OaPeRfj4jejW8Z1T0swq0w/W6WY1QBT0eN8YQ0sSMUAkZM Y=; X-IronPort-AV: E=Sophos;i="4.93,567,1378857600"; d="scan'208";a="36194409" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 25 Oct 2013 01:45:55 +0000 Received: from tky-shtsuchi-8916.cisco.com (tky-shtsuchi-8916.cisco.com [10.71.44.87]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9P1jgK7031118; Fri, 25 Oct 2013 01:45:45 GMT Message-ID: <5269CD46.3050909@cisco.com> Date: Fri, 25 Oct 2013 10:45:42 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: rtg-bfd@ietf.org Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 References: <20131024191431.GO17538@pfrc> In-Reply-To: <20131024191431.GO17538@pfrc> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 01:46:23 -0000 support Regards, -Shishio (2013/10/25 4:14), Jeffrey Haas wrote: > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > The last call will complete on November 8, the end of IETF week. Time will > be available during the Vancouver IETF BFD session to discuss last call > comments. > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. > > Due to the small nature of the BFD working group and the fact that both > working group chairs have contributed to this document, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an > independent party to gauge working group consensus. > > In order to facilitate the transparency of this WGLC, please remember to > send all comments to the working group mailing list. > > IPR declarations have been filed against this draft and the document authors > and contributors have been polled for any further IPR. Current IPR > declarations may be seen at the following link: > > http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-bfd-on-lags > > If you are aware of additional IPR against this document please declare so, per > the IETF Note Well. > > Finally, the IEEE has expressed interest in the disposition of this draft. > They will likely provide additional commentary, if any, via the IETF liaison > process. This process will likely happen after WGLC concludes. Depending > on their feedback, WGLC may re-open to address their concerns. > > -- Jeff (for the chairs) > . > From venggovi@cisco.com Thu Oct 24 22:00:31 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB01F11E810F for ; Thu, 24 Oct 2013 22:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYraHDrC5eL0 for ; Thu, 24 Oct 2013 22:00:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EAF8011E8105 for ; Thu, 24 Oct 2013 22:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1830; q=dns/txt; s=iport; t=1382677226; x=1383886826; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SjuZgvZutSb5ZnPjdaobud0z4MArFpMDadFvV71NNqs=; b=Nkjynu+rZvzD0jSPsy2HyE+EYcy4JWP0lOqoSRGIhhEST6wTFF7uTGME 833JPN/ci6b9XUT7BCM45A6zK9wBR8bB/6umJFi5RqOSVzlysYWLyASe0 APNvsvFEyfd7w4jifLxSA4IoTiBw7iwP9BxVSFCXt7b0pqsUX1evap3gc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAGT6aVKtJXG9/2dsb2JhbABZgwc4VL4/gSQWdIIlAQEBBDo0FwQCAQgOAwQBAQsUCQcyFAkIAgQBEgiHfw25bY4EgRg4BoMZgQ0DlCqFD5BYgySBcTk X-IronPort-AV: E=Sophos;i="4.93,567,1378857600"; d="scan'208";a="276258631" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 25 Oct 2013 05:00:18 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9P50Hxm007470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 05:00:17 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 00:00:17 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0O1Y9elQc5FlH02GsgQf7LYBT5oE3DLA Date: Fri, 25 Oct 2013 05:00:17 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> References: <20131024191431.GO17538@pfrc> In-Reply-To: <20131024191431.GO17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.1.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 05:00:31 -0000 Support -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Friday, October 25, 2013 12:45 AM To: rtg-bfd@ietf.org Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends November = 8 This email is to initiate working group last call on the BFD on Link Aggreg= ate Group Interfaces document: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 The last call will complete on November 8, the end of IETF week. Time will= be available during the Vancouver IETF BFD session to discuss last call co= mments. Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. Due to the small nature of the BFD working group and the fact that both wor= king group chairs have contributed to this document, we have gotten Carlos = Pignataro (cpignata@cisco.com) to volunteer to serve as an independent part= y to gauge working group consensus. In order to facilitate the transparency of this WGLC, please remember to se= nd all comments to the working group mailing list. IPR declarations have been filed against this draft and the document author= s and contributors have been polled for any further IPR. Current IPR decla= rations may be seen at the following link: http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft= -ietf-bfd-on-lags If you are aware of additional IPR against this document please declare so,= per the IETF Note Well. Finally, the IEEE has expressed interest in the disposition of this draft. They will likely provide additional commentary, if any, via the IETF liaiso= n process. This process will likely happen after WGLC concludes. Dependin= g on their feedback, WGLC may re-open to address their concerns. -- Jeff (for the chairs) From tnadeau@lucidvision.com Fri Oct 25 05:01:16 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B02711E8319 for ; Fri, 25 Oct 2013 05:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp6J-TgKjSTd for ; Fri, 25 Oct 2013 05:01:11 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 024DA11E83B3 for ; Fri, 25 Oct 2013 05:01:06 -0700 (PDT) Received: from [192.168.1.113] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D05D225BD1A9; Fri, 25 Oct 2013 08:01:03 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_73971543-A8DC-4D15-A7BA-5AFBAE54D18E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: WGLC for BFD base MIB and TC - ends November 8 From: Thomas Nadeau In-Reply-To: <3AC6B50876817C4AAFBF414E8F6090F71EFD38C3@xmb-aln-x11.cisco.com> Date: Fri, 25 Oct 2013 08:00:59 -0400 Message-Id: <385E1583-09F8-4413-9A32-7F5EF191F890@lucidvision.com> References: <3AC6B50876817C4AAFBF414E8F6090F71EFD38C3@xmb-aln-x11.cisco.com> To: "Srihari Raghavan (srihari)" X-Mailer: Apple Mail (2.1816) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 12:01:16 -0000 --Apple-Mail=_73971543-A8DC-4D15-A7BA-5AFBAE54D18E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please send detailed comments on any requested changes rather = than "support/do not support" during the WG last call. --Tom On Oct 24, 2013:9:08 PM, at 9:08 PM, Srihari Raghavan (srihari) = wrote: > Yes/Support. >=20 > Thanks > Srihari >=20 > On 25/10/13 12:36 AM, "Jeffrey Haas" wrote: >=20 >> This email is to initiate working group last call on the BFD MIB and >> Textual-Convention documents: >>=20 >> http://tools.ietf.org/html/draft-ietf-bfd-mib-14 >> http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 >>=20 >> The last call will complete on November 8, the end of IETF week. = Time >> will >> be available during the Vancouver IETF BFD session to discuss last = call >> comments. >>=20 >> I will be serving as document shepherd (RFC 4858) for this WGLC. >>=20 >> Due to the small nature of the BFD working group and the fact that = both >> working group chairs have contributed to the documents, we have = gotten >> Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an >> independent party to gauge working group consensus. >>=20 >> In order to facilitate the transparency of this WGLC, please remember = to >> send all comments to the working group mailing list. >>=20 >> As is often the case with MIB documents, implementations typically do = not >> exist for the final form of the document. Typically enterprise MIBs = are >> implemented at some point in the document life cycle and then later = the >> implementor will revise to match the published RFC, including OID >> code-points assigned by IANA. Reviewers examining the MIB against >> deployed >> implementations are requested to bear in mind implementability of the >> final >> document vs. existence proof of the running code. >>=20 >> Finally, note that no IPR polling has been done for these documents. >> MIBs, >> being IETF data models of things that themselves may have IPR, tend = not to >> have IPR against them. However, if someone is aware of IPR against = these >> documents, please state it for the WG. >>=20 >> -- Jeff (for the chairs) >=20 >=20 --Apple-Mail=_73971543-A8DC-4D15-A7BA-5AFBAE54D18E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJSal17AAoJEPcO+I7eiUJZWDMP/10z3XiZ7xaiEnpJJUSpxZxT I5Q3RJT7odvpiunNHtlWexW2+iBd34pbpb+vp+shO/cklGDYw8+rdU5/8iJ6xGqn 09PtX9BrX6RmLYoOq6HwHxB+rS5V1IpK4zzre4dsZAs4YiTknnoClbGtazOhBU4/ Z9955/2s4/0OPQMtsSyPvPXw9osAVaBschHI70aKuKDRdAAf6YQ8hGTXZvTcAWkf Uj/ka38Lev9i8foLhphSDtGHAn4oN7M0ZDPLbLfrP4+RzDXcklaW10yOL9cfjNDh MCtKzkjyPgRjyMLyvb4Ol4fU/9RWOM/824P64+O1EcFVU6I0kl/lJLFZcbuJiVay 9WMivAUS99789UetHqRhP59B5tOlUYGnvW9SJljj9xDXQVJp8j6in3HI4mJ/JVtM KY47Fvqyy+30sW3zXkMt6PQhVGlTxOnd/1gINthiLWXnO4MeUVOemHNIc3YR3AZW jt4eIewtoMjYMffs+FmB+aF9pkzkL0/z2ft9hr69ryFmk//0fbZ0isMAd5zesRCC F4V1VGA2ENaWVWdRHDg6E+pshV8YssA7+71nhXgSCQAU0j6bv0HKkJHXVC9mDisL M+c9326RQ+dQz/ZHwpgRIO4N6MiX47ObvKxrsLMHdBvoq6/Acc3nsb0ohk/R6v/V Tlpt/+mweDVcSyn0AZ2W =/qci -----END PGP SIGNATURE----- --Apple-Mail=_73971543-A8DC-4D15-A7BA-5AFBAE54D18E-- From jhaas@slice.pfrc.org Fri Oct 25 06:51:48 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562C011E8256 for ; Fri, 25 Oct 2013 06:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T2sBDxeGH8O for ; Fri, 25 Oct 2013 06:51:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 61D2611E81A8 for ; Fri, 25 Oct 2013 06:51:40 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 09E96C238; Fri, 25 Oct 2013 09:51:40 -0400 (EDT) Date: Fri, 25 Oct 2013 09:51:40 -0400 From: Jeffrey Haas To: Thomas Nadeau Subject: Re: WGLC for BFD base MIB and TC - ends November 8 Message-ID: <20131025135139.GV17538@pfrc> References: <3AC6B50876817C4AAFBF414E8F6090F71EFD38C3@xmb-aln-x11.cisco.com> <385E1583-09F8-4413-9A32-7F5EF191F890@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <385E1583-09F8-4413-9A32-7F5EF191F890@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 13:51:48 -0000 On Fri, Oct 25, 2013 at 08:00:59AM -0400, Thomas Nadeau wrote: > Please send detailed comments on any requested changes rather than "support/do not support" during the WG last call. Thanks, Tom. :-) I agree. If all of you who have responded "support" really mean "I have thoroughly read and support the last call of the current draft", that's a lot of good review. I'm a bit skeptical. -- Jeff From wim.henderickx@alcatel-lucent.com Fri Oct 25 07:08:02 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3925211E83FC for ; Fri, 25 Oct 2013 07:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkKXnAc9rVrY for ; Fri, 25 Oct 2013 07:07:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3057411E83C9 for ; Fri, 25 Oct 2013 07:07:42 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9PE7VUE006984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2013 09:07:32 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9PE7942003914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 16:07:30 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.193]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 16:07:27 +0200 From: "Henderickx, Wim (Wim)" To: Jeffrey Haas , Thomas Nadeau Subject: Re: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO0Yl5GZn0Jk+FvEuFs+gNV4w+dZoFc/qA Date: Fri, 25 Oct 2013 14:07:26 +0000 Message-ID: In-Reply-To: <20131025135139.GV17538@pfrc> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <7AB1D9BE704FE6469BE34FC9456FE090@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 14:08:02 -0000 This is how I replied. No comments on the doc and read it carefully + implemented :-) On 25/10/13 15:51, "Jeffrey Haas" wrote: >On Fri, Oct 25, 2013 at 08:00:59AM -0400, Thomas Nadeau wrote: >> Please send detailed comments on any requested changes rather than >>"support/do not support" during the WG last call. > >Thanks, Tom. :-) > >I agree. If all of you who have responded "support" really mean "I have >thoroughly read and support the last call of the current draft", that's a >lot of good review. > >I'm a bit skeptical. > >-- Jeff From tnadeau@lucidvision.com Fri Oct 25 07:21:32 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B500611E81BB for ; Fri, 25 Oct 2013 07:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M09eQLmz4F04 for ; Fri, 25 Oct 2013 07:21:26 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id EE85D11E8270 for ; Fri, 25 Oct 2013 07:21:18 -0700 (PDT) Received: from [192.168.1.113] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5555225BD97F; Fri, 25 Oct 2013 10:21:18 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FCC992E7-1DE2-46E0-83DE-4BC6A53EA147"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: WGLC for BFD base MIB and TC - ends November 8 From: Thomas Nadeau In-Reply-To: Date: Fri, 25 Oct 2013 10:21:16 -0400 Message-Id: <57644E95-D2B9-4831-8F49-D0E53CD90B27@lucidvision.com> References: To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1816) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 14:21:32 -0000 --Apple-Mail=_FCC992E7-1DE2-46E0-83DE-4BC6A53EA147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Perfect! Cheers, --Tom On Oct 25, 2013:10:07 AM, at 10:07 AM, Henderickx, Wim (Wim) = wrote: > This is how I replied. No comments on the doc and read it carefully + > implemented :-) >=20 > On 25/10/13 15:51, "Jeffrey Haas" wrote: >=20 >> On Fri, Oct 25, 2013 at 08:00:59AM -0400, Thomas Nadeau wrote: >>> Please send detailed comments on any requested changes rather than >>> "support/do not support" during the WG last call. >>=20 >> Thanks, Tom. :-) >>=20 >> I agree. If all of you who have responded "support" really mean "I = have >> thoroughly read and support the last call of the current draft", = that's a >> lot of good review. >>=20 >> I'm a bit skeptical. >>=20 >> -- Jeff >=20 >=20 --Apple-Mail=_FCC992E7-1DE2-46E0-83DE-4BC6A53EA147 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJSan5cAAoJEPcO+I7eiUJZuGUQALK5skJBQg/+0PVHVAx+OowW xrcf/glAvEM+P1t1I5BHIBM3ljApXwN3YNuCHzfOUJMgEwNr5WmprzNRpdlGt98y bI23i+Tdbjjad+QT5JfesDB7tj4jLAP+y4E/p4zg619a35eZWH58uMoLxwgpEcnv TiPgvkXSMXJ4Vq5bp6So7uumvD/ENgcvNpVvc6HlJWeHXfoVyyjzaM2s2KF9FVfg 99dnCiXZFBGf4/lDikSdKkjBenFJbTPzrT0de9C41BubndGYp44wDev+2YA7/m7U razhMtm4PdtbzHoRXTsTJtHWluoqxEirA4azfXdQkFUgtuHp7cGE5+/4cJwmtvDz +fVhZbOLmz9MUtT+8v3kSzCaOOG1KCrT1FU8XbA+d/n803IRQ7cLTYIESPFqhG4Y 1bFp3tkijOlKKorqkEy/CCBVZro0oMjqnZr0k6v5tjUkcHBqWrlh7nMfYqSyNF8G 0AOKhxSrQ0Bj8zF0O2r2eizY7sudlRZ6FJt4KChylbcVLb67iFQ3elXDQQMIWwMV H8teE2YiCwSNAyox2we0/PhBjnNNrI/sBi5CqC3DWGnReVwsyQ30muFnwwjIm8Jb W8kFokqwHgs0rSL4r8byYy3fDg2dJIUEKIzjVtR4SPHWNfHFN/mEUltlfLgCxqaQ PD4XD/W8J++6r82D/yhV =fHdP -----END PGP SIGNATURE----- --Apple-Mail=_FCC992E7-1DE2-46E0-83DE-4BC6A53EA147-- From mjethanandani@gmail.com Fri Oct 25 09:30:34 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7377B11E832A for ; Fri, 25 Oct 2013 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 803zEs0W66Xd for ; Fri, 25 Oct 2013 09:30:30 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C7E1C11E819F for ; Fri, 25 Oct 2013 09:30:30 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id ar20so6638843iec.26 for ; Fri, 25 Oct 2013 09:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tdfYtc+9OWjiiwZpoFfWPhsct2BQ8wYhsnEkXxp878s=; b=U9tcVtH/C/2OB39QE5qS9Nc0/cPsL1Jfy6KgdCTz/4KmluoTHTXUlCnuoB2w7MuYY4 wzcdJq0CS5YQK01/vhIBkrT0jDW43vwkGkbbxbIrq2KTE7nXW+KiAiKt6WcAX6BZwJcj hqYVUmRaN8KN0nctcfN271OWNaSwKz8lAihqTr1HIdid+2Eg7ydtGibLH/CF0FWgsx8S 7cVS40TcyCLbRo6uNFMt7tVJtygEGfpSxOy44PCr5G/MZ8VeEdKnQ45aSNxjI8wdRxB9 BhtR01UskEGBlBpvaAudjISWx/wdjt8gExf85g4d0TReC77gk6xO+qhnEy65qWpB31Su UEFg== X-Received: by 10.50.25.129 with SMTP id c1mr2863086igg.23.1382718630129; Fri, 25 Oct 2013 09:30:30 -0700 (PDT) Received: from [192.168.1.101] (108-247-126-202.lightspeed.sntcca.sbcglobal.net. [108.247.126.202]) by mx.google.com with ESMTPSA id ih14sm3743326igb.7.2013.10.25.09.30.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 09:30:29 -0700 (PDT) Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> Date: Fri, 25 Oct 2013 09:30:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> To: Vengada Prasad Govindan (venggovi) X-Mailer: Apple Mail (2.1085) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 16:30:34 -0000 I am not clear on the fact whether the draft is talking about BFD = session between two boxes that are one hop away and have a LAG between = them. I assume it does not address the case where the LAG might be in = the middle of the network, where one or both ends of the LAG are not the = end points of the BFD session. The document talks about using IP/UDP encapsulation on each micro BFD = session. How will this work on MPLS-TP tunnels running over a LAG? For initial DOWN BFD packet, where the Your Discriminator field is 0, = the draft suggests that demultiplexing MUST be based on some combination = of other fields which MUST include the interface information of the = member link. That assumes that systems are aware of what interface the = BFD packet came on. That is not always the case, and in a global = label/IP space, systems do not have to know the physical link traffic = came on. I am struggling to suggest an alternative, but would like to = see the issue addressed particularly since it is a MUST. Same is true for the procedure for the reception of BFD control packet = and its verification of the interface that it came on. On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote: > Support >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Jeffrey Haas > Sent: Friday, October 25, 2013 12:45 AM > To: rtg-bfd@ietf.org > Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends = November 8 >=20 > This email is to initiate working group last call on the BFD on Link = Aggregate Group Interfaces document: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >=20 > The last call will complete on November 8, the end of IETF week. Time = will be available during the Vancouver IETF BFD session to discuss last = call comments. >=20 > Nobo Akiya will be serving as document shepherd (RFC 4858) for this = WGLC. >=20 > Due to the small nature of the BFD working group and the fact that = both working group chairs have contributed to this document, we have = gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an = independent party to gauge working group consensus. >=20 > In order to facilitate the transparency of this WGLC, please remember = to send all comments to the working group mailing list. >=20 > IPR declarations have been filed against this draft and the document = authors and contributors have been polled for any further IPR. Current = IPR declarations may be seen at the following link: >=20 > = http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-bfd-on-lags >=20 > If you are aware of additional IPR against this document please = declare so, per the IETF Note Well. >=20 > Finally, the IEEE has expressed interest in the disposition of this = draft. > They will likely provide additional commentary, if any, via the IETF = liaison process. This process will likely happen after WGLC concludes. = Depending on their feedback, WGLC may re-open to address their concerns. >=20 > -- Jeff (for the chairs) Mahesh Jethanandani mjethanandani@gmail.com From venggovi@cisco.com Fri Oct 25 23:26:15 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36B21F995A for ; Fri, 25 Oct 2013 23:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK5aeenydmJf for ; Fri, 25 Oct 2013 23:26:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC7711E827E for ; Fri, 25 Oct 2013 23:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1037; q=dns/txt; s=iport; t=1382768755; x=1383978355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ikU1hGvAXJtpNK9kativkNUTSrGV5UBygwdABSaoj88=; b=BEh4GuCdN7QM/SreQZ/lXQKxYrmdr1ZhiEyFDvk1/8hgGZWME0pIxkCs wviTyBgt7kDiyQMD9ap19yBdvOcFylI+3MVOheePD6iuHvQ9UL0ia8TUt E48RHtND0k8xIv698fkZ5h0hWfpwXSvX+ecpaC95mNZ1ZNarHpTjtq/+5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFABVga1KtJV2Z/2dsb2JhbABZgweBDL5JgR4WdIIlAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQJCAIEAQ0FCId/uGiPIjEHBoMZgQ0DqhGDJoIq X-IronPort-AV: E=Sophos;i="4.93,575,1378857600"; d="scan'208";a="276927628" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 26 Oct 2013 06:25:44 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9Q6Pi6E028281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Oct 2013 06:25:44 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 26 Oct 2013 01:25:44 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , Thomas Nadeau Subject: RE: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO0Owj6lxOQAJNqk66Mg+bUpscV5oE71MAgAC2YoCAAB7tAIAAwQtg Date: Sat, 26 Oct 2013 06:25:43 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D337EE068@xmb-rcd-x15.cisco.com> References: <3AC6B50876817C4AAFBF414E8F6090F71EFD38C3@xmb-aln-x11.cisco.com> <385E1583-09F8-4413-9A32-7F5EF191F890@lucidvision.com> <20131025135139.GV17538@pfrc> In-Reply-To: <20131025135139.GV17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 06:26:15 -0000 Hello Jeff, >I agree. If all of you who have responded "support" really mean "I have t= horoughly read and support the last call of the current draft", that's a lo= t >of good review. I submit that I have reviewed the document and do not have specific comment= s. I am part of a team that handles implementation of this draft. Thanks Prasad -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Friday, October 25, 2013 7:22 PM To: Thomas Nadeau Cc: rtg-bfd@ietf.org Subject: Re: WGLC for BFD base MIB and TC - ends November 8 On Fri, Oct 25, 2013 at 08:00:59AM -0400, Thomas Nadeau wrote: > Please send detailed comments on any requested changes rather than "suppo= rt/do not support" during the WG last call. Thanks, Tom. :-) I agree. If all of you who have responded "support" really mean "I have th= oroughly read and support the last call of the current draft", that's a lot= of good review. I'm a bit skeptical. -- Jeff From manav.bhatia@alcatel-lucent.com Sun Oct 27 04:38:19 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492AB11E8171 for ; Sun, 27 Oct 2013 04:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCyUkYvhV1JA for ; Sun, 27 Oct 2013 04:37:47 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D143211E815F for ; Sun, 27 Oct 2013 04:37:46 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9RBbhBp028657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Oct 2013 06:37:44 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r9RBbhE4012196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Oct 2013 07:37:43 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 27 Oct 2013 07:37:43 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Sun, 27 Oct 2013 19:37:38 +0800 From: "Bhatia, Manav (Manav)" To: Mahesh Jethanandani , Vengada Prasad Govindan Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0Z+DNFj/MU8qmUKBYON0YuBEtZoIbKoA Date: Sun, 27 Oct 2013 11:37:37 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> In-Reply-To: <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 11:38:21 -0000 Hi Mahesh, This draft only talks about BFD sessions between directly connected boxes. > For initial DOWN BFD packet, where the Your Discriminator field is 0, > the draft suggests that demultiplexing MUST be based on some > combination of other fields which MUST include the interface > information of the member link. That assumes that systems are aware of > what interface the BFD packet came on. That is not always the case, and > in a global label/IP space, systems do not have to know the physical Can you explain the scenario where you think its not possible for a system = to know the ifindex of the IP interface over which an incoming packet arriv= ed? > link traffic came on. I am struggling to suggest an alternative, but > would like to see the issue addressed particularly since it is a MUST. >=20 > Same is true for the procedure for the reception of BFD control packet > and its verification of the interface that it came on. I think youre missing something because we already have 3 interoperable imp= lementations of this draft. Clearly, those implementations were able to ide= ntify the IP interface over which the uBFD packet arrived. Cheers, Manav >=20 > On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote: >=20 > > Support > > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > > Sent: Friday, October 25, 2013 12:45 AM > > To: rtg-bfd@ietf.org > > Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends > November 8 > > > > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: > > > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > > > The last call will complete on November 8, the end of IETF week. > Time will be available during the Vancouver IETF BFD session to discuss > last call comments. > > > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this > WGLC. > > > > Due to the small nature of the BFD working group and the fact that > both working group chairs have contributed to this document, we have > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as > an independent party to gauge working group consensus. > > > > In order to facilitate the transparency of this WGLC, please remember > to send all comments to the working group mailing list. > > > > IPR declarations have been filed against this draft and the document > authors and contributors have been polled for any further IPR. Current > IPR declarations may be seen at the following link: > > > > > http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft > -ietf-bfd-on-lags > > > > If you are aware of additional IPR against this document please > declare so, per the IETF Note Well. > > > > Finally, the IEEE has expressed interest in the disposition of this > draft. > > They will likely provide additional commentary, if any, via the IETF > liaison process. This process will likely happen after WGLC concludes. > Depending on their feedback, WGLC may re-open to address their > concerns. > > > > -- Jeff (for the chairs) >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 From cpignata@cisco.com Tue Oct 29 05:16:36 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A31B11E8230 for ; Tue, 29 Oct 2013 05:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkTQZQUT-VXs for ; Tue, 29 Oct 2013 05:16:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC611E813F for ; Tue, 29 Oct 2013 05:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2999; q=dns/txt; s=iport; t=1383048990; x=1384258590; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y6UAV6al7YqHj2bLbMHEt8ElU3GD9WJ8DLX7EK9/ja8=; b=Sd5r4+LbfJ59Mj3T8f3pMAMgYgns7p5cevRspFjDhBwyJhFvF/GGNTBC s16FBal9pkoLDtQfE9+AJv6DSh/kMrkdvkJxYEkEspQsJNCXIjaeRwYj3 4EC0DW99zZDArwTZH+qdBm7FS1IxGrMxsGnJkHLWKzRJpYKrIplx8bS3e k=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAF+mb1KtJXG+/2dsb2JhbABZgwc4VL8ygSUWdIIlAQEBAwFuCwULAgEIDhQkMiUCBA4FCAYLh2gGDbk+jE+BL4EYMQeDH4ENA5AtgTCCTYUPkFmDJoFxOQ X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="asc'?scan'208";a="277962130" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2013 12:16:30 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9TCGTtE002657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 12:16:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 07:16:29 -0500 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas Subject: Re: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO0Owj9BHfQgfTCEu2bFQKEE0D/JoL81wA Date: Tue, 29 Oct 2013 12:16:28 +0000 Message-ID: <95067C434CE250468B77282634C96ED333632755@xmb-aln-x02.cisco.com> References: <20131024190612.GN17538@pfrc> In-Reply-To: <20131024190612.GN17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.145] Content-Type: multipart/signed; boundary="Apple-Mail=_4EB71FE4-D0CC-4E36-836F-F244B0245885"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 12:16:36 -0000 --Apple-Mail=_4EB71FE4-D0CC-4E36-836F-F244B0245885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [as an individual] I have read both these documents and support their progress. They are = well written, and fill an important gap. There are, however, a set of Nits found by idnits. These are = straightforward but should be fixed before sending the doc upstream. = http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-bfd= -mib-14.txt = http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-bfd= -tc-mib-02.txt Thanks, -- Carlos. On Oct 24, 2013, at 3:06 PM, Jeffrey Haas wrote: > This email is to initiate working group last call on the BFD MIB and > Textual-Convention documents: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-mib-14 > http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 >=20 > The last call will complete on November 8, the end of IETF week. Time = will > be available during the Vancouver IETF BFD session to discuss last = call > comments. >=20 > I will be serving as document shepherd (RFC 4858) for this WGLC.=20 >=20 > Due to the small nature of the BFD working group and the fact that = both > working group chairs have contributed to the documents, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an > independent party to gauge working group consensus. >=20 > In order to facilitate the transparency of this WGLC, please remember = to > send all comments to the working group mailing list. >=20 > As is often the case with MIB documents, implementations typically do = not > exist for the final form of the document. Typically enterprise MIBs = are > implemented at some point in the document life cycle and then later = the > implementor will revise to match the published RFC, including OID > code-points assigned by IANA. Reviewers examining the MIB against = deployed > implementations are requested to bear in mind implementability of the = final > document vs. existence proof of the running code. >=20 > Finally, note that no IPR polling has been done for these documents. = MIBs, > being IETF data models of things that themselves may have IPR, tend = not to > have IPR against them. However, if someone is aware of IPR against = these > documents, please state it for the WG. >=20 > -- Jeff (for the chairs) --Apple-Mail=_4EB71FE4-D0CC-4E36-836F-F244B0245885 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJvpxwACgkQtfDPGTp3USy7RwCggkvzUgnVNZCazkdPjbBKOkUd SnIAn3eIiCerG4jmWW5m/txgNLnwBxi6 =gNRh -----END PGP SIGNATURE----- --Apple-Mail=_4EB71FE4-D0CC-4E36-836F-F244B0245885-- From cpignata@cisco.com Tue Oct 29 05:18:40 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6F11E81AB for ; Tue, 29 Oct 2013 05:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s0OvhFSA4wQ for ; Tue, 29 Oct 2013 05:18:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 524CE11E8171 for ; Tue, 29 Oct 2013 05:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2832; q=dns/txt; s=iport; t=1383049115; x=1384258715; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dJjdRT6A8wcV3JSD1lLGT6fnj9vwSZFFAt40KKB6aQ0=; b=hydd4IvWas1pNUKlvBqqjqbmtxGlw2HhMBdG8Ruz9W4Anofty3lk3mCz 4leaZI+/8PuflJ2NRqQQQ+9lqKA9UaUs9PlzvGlHWCWoBq8Tbmb+b71KG 1J6J6e2cWxRUxzo164v4V/X3Popd1TpB9NyOL+i0l5KljGPLXpTWvD17D Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJamb1KtJXG8/2dsb2JhbABZgwc4VL8ygSUWdIIlAQEBAwFuCwULAgEIDhQkMiUCBA4FCAaHcwYNuT+MT4EvgRgxB4MfgQ0DkC2BMIJNhQ+QWYMmgXE5 X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="asc'?scan'208";a="277766862" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 29 Oct 2013 12:18:34 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9TCIYKU010686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 12:18:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 07:18:34 -0500 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0O1YIIyKixBBUE25sptvk5frqZoL8+4A Date: Tue, 29 Oct 2013 12:18:33 +0000 Message-ID: <95067C434CE250468B77282634C96ED33363277B@xmb-aln-x02.cisco.com> References: <20131024191431.GO17538@pfrc> In-Reply-To: <20131024191431.GO17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.145] Content-Type: multipart/signed; boundary="Apple-Mail=_0D669C27-D143-4C8E-A6BE-D5E02F3F7B24"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 12:18:40 -0000 --Apple-Mail=_0D669C27-D143-4C8E-A6BE-D5E02F3F7B24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [as an individual] Hi, I've followed this document and have also read the current version under = WGLC. I support its publication as it solves a real problem and is very = comprehensively written. There are one or two small nits (broken citations/references) that ought = to be fixed: = http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-bfd= -on-lags-01.txt Thanks, -- Carlos. On Oct 24, 2013, at 3:14 PM, Jeffrey Haas wrote: > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >=20 > The last call will complete on November 8, the end of IETF week. Time = will > be available during the Vancouver IETF BFD session to discuss last = call > comments. >=20 > Nobo Akiya will be serving as document shepherd (RFC 4858) for this = WGLC. >=20 > Due to the small nature of the BFD working group and the fact that = both > working group chairs have contributed to this document, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an=20 > independent party to gauge working group consensus. >=20 > In order to facilitate the transparency of this WGLC, please remember = to=20 > send all comments to the working group mailing list. >=20 > IPR declarations have been filed against this draft and the document = authors > and contributors have been polled for any further IPR. Current IPR > declarations may be seen at the following link: >=20 > = http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-bfd-on-lags >=20 > If you are aware of additional IPR against this document please = declare so, per > the IETF Note Well. >=20 > Finally, the IEEE has expressed interest in the disposition of this = draft. > They will likely provide additional commentary, if any, via the IETF = liaison > process. This process will likely happen after WGLC concludes. = Depending > on their feedback, WGLC may re-open to address their concerns. >=20 > -- Jeff (for the chairs) --Apple-Mail=_0D669C27-D143-4C8E-A6BE-D5E02F3F7B24 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJvp5gACgkQtfDPGTp3USzBAQCgycT+i3sAytbePP+anTQLeQMA VKoAoJAyC/MU4iPp54c2FKH7xqD1hisq =4P2G -----END PGP SIGNATURE----- --Apple-Mail=_0D669C27-D143-4C8E-A6BE-D5E02F3F7B24-- From mjethanandani@gmail.com Tue Oct 29 16:47:04 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8408811E80E7 for ; Tue, 29 Oct 2013 16:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc0JmfukOJey for ; Tue, 29 Oct 2013 16:47:01 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 58F6011E81C5 for ; Tue, 29 Oct 2013 16:46:58 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jz11so456901veb.6 for ; Tue, 29 Oct 2013 16:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B8KmoW/WZmCSDd57EUwlZ7aasfl8xyYbGJvC/+2gPMM=; b=YxOhwg+tyb6iAkZOb5xztoQIELG7G8ZS6sP5Iw5XF/m82CEr3a5WkslDAspR5DRMoM xFhS56rsPFbpf+QoZXSvSMfGwMDoWrHECDTBoOXSnfYJbVgIHFhfFto7i0g+KY2p9d45 VdyVXkHi6EY4fRu/1m5BPr8xk3fN0mx85bDVpWaXgMQYIOEO4s11ml/jLCPzGfuzGnIu 7M0Fn8h6XbIrnwvXzLPd/LBk9iNCRtA7JlwdzCFMMPoeReoLiF76aZ5fM7ED8luTTLyg fSlE46mBpxQrDW7c4by7MMbsuIhbB7QbmfLZKWqLAgWjrKGqfTBjP0T02C5nk0tS5mgH ku0w== MIME-Version: 1.0 X-Received: by 10.221.6.195 with SMTP id ol3mr1079525vcb.34.1383090417830; Tue, 29 Oct 2013 16:46:57 -0700 (PDT) Received: by 10.52.34.16 with HTTP; Tue, 29 Oct 2013 16:46:57 -0700 (PDT) In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Tue, 29 Oct 2013 16:46:57 -0700 Message-ID: Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 From: Mahesh Jethanandani To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=089e013cbc8c0c1a1704e9e9d5cc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 23:47:04 -0000 --089e013cbc8c0c1a1704e9e9d5cc Content-Type: text/plain; charset=ISO-8859-1 Manav, I have problems with the draft in its current format for two reasons. The fundamental issue is that the proposal requires BFD protocol to rely on information that is not carried in the frame itself. Unless by interface check you mean check against IP address. I do not know of many protocols that require one to validate/use information that is not part of the frame itself. Protocols that have stood the test of time, like TCP, do not look beyond their own layers in the frame for validation of a frame. Even if we have breached the OSI layer, at least we have restricted ourselves to looking at what is in the frame. The second issue as I highlighted is that there is an assumption that systems carry interface information up to the protocol itself for it to validate/use the information. Again, I assume you mean the check will be against the physical interface and not the IP address. That as I mentioned is a huge assumption. There is no precedence for this. There are couple of ways to solve the problem. One way would be to use the IP address on the individual member link to map a packet to a BFD session running on a member link. When the initial BFD frame is received with your discriminator as zero, you would use the destination IP address contained in the packet to figure out which link the packet was received on. The same would be true of validation of frame. This will not work for unnumbered interfaces. The other would be use the individual link MAC address as a way to co-relate a BFD packet to a particular link both to set up a BFD session (when the discriminator is zero) and for future validation of the frame (to a particular link). This would mean that we cannot use the multicast address to send the BFD frame. How the IP/MAC address is collected and setup is beyond the scope of this document. On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Hi Mahesh, > > This draft only talks about BFD sessions between directly connected boxes. > > > For initial DOWN BFD packet, where the Your Discriminator field is 0, > > the draft suggests that demultiplexing MUST be based on some > > combination of other fields which MUST include the interface > > information of the member link. That assumes that systems are aware of > > what interface the BFD packet came on. That is not always the case, and > > in a global label/IP space, systems do not have to know the physical > > Can you explain the scenario where you think its not possible for a system > to know the ifindex of the IP interface over which an incoming packet > arrived? > > > link traffic came on. I am struggling to suggest an alternative, but > > would like to see the issue addressed particularly since it is a MUST. > > > > Same is true for the procedure for the reception of BFD control packet > > and its verification of the interface that it came on. > > I think youre missing something because we already have 3 interoperable > implementations of this draft. Clearly, those implementations were able to > identify the IP interface over which the uBFD packet arrived. > > Cheers, Manav > > > > > On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote: > > > > > Support > > > > > > -----Original Message----- > > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Jeffrey Haas > > > Sent: Friday, October 25, 2013 12:45 AM > > > To: rtg-bfd@ietf.org > > > Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends > > November 8 > > > > > > This email is to initiate working group last call on the BFD on Link > > Aggregate Group Interfaces document: > > > > > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > > > > > The last call will complete on November 8, the end of IETF week. > > Time will be available during the Vancouver IETF BFD session to discuss > > last call comments. > > > > > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this > > WGLC. > > > > > > Due to the small nature of the BFD working group and the fact that > > both working group chairs have contributed to this document, we have > > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as > > an independent party to gauge working group consensus. > > > > > > In order to facilitate the transparency of this WGLC, please remember > > to send all comments to the working group mailing list. > > > > > > IPR declarations have been filed against this draft and the document > > authors and contributors have been polled for any further IPR. Current > > IPR declarations may be seen at the following link: > > > > > > > > http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft > > -ietf-bfd-on-lags > > > > > > If you are aware of additional IPR against this document please > > declare so, per the IETF Note Well. > > > > > > Finally, the IEEE has expressed interest in the disposition of this > > draft. > > > They will likely provide additional commentary, if any, via the IETF > > liaison process. This process will likely happen after WGLC concludes. > > Depending on their feedback, WGLC may re-open to address their > > concerns. > > > > > > -- Jeff (for the chairs) > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > -- Mahesh Jethanandani mjethanandani@gmail.com --089e013cbc8c0c1a1704e9e9d5cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Manav,

I have problems with the draft i= n its current format for two reasons.

The fundamen= tal issue is that the proposal requires BFD protocol to rely on information= that is not carried in the frame itself. Unless by interface check you mea= n check against IP address. I do not know of many protocols that require on= e to validate/use information that is not part of the frame itself. Protoco= ls that have stood the test of time, like TCP, do not look beyond their own= layers in the frame for validation of a frame. Even if we have breached th= e OSI layer, at least we have restricted ourselves to looking at what is in= the frame.

The second issue as I highlighted is that there is an a= ssumption that systems carry interface information up to the protocol itsel= f for it to validate/use the information. Again, I assume you mean the chec= k will be against the physical interface and not the IP address. That as I = mentioned is a huge assumption. There is no precedence for this.

There are couple of ways to solve the problem.

One way would be to use the IP address on the individual m= ember link to map a packet to a BFD session running on a member link. When = the initial BFD frame is received with your discriminator as zero, you woul= d use the destination IP address contained in the packet to figure out whic= h link the packet was received on. The same would be true of validation of = frame. This will not work for unnumbered interfaces.

The other would be use the individual link MAC address = as a way to co-relate a BFD packet to a particular link both to set up a BF= D session (when the discriminator is zero) and for future validation of the= frame (to a particular link). This would mean that we cannot use the multi= cast address to send the BFD frame.

How the IP/MAC address is collected and setup is beyond= the scope of this document.


=
On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (= Manav) <manav.bhatia@alcatel-lucent.com> wrote= :
Hi Mahesh,

This draft only talks about BFD sessions between directly connected boxes.<= br>

> For initial DOWN BFD packet, where the Your Discriminator field is 0,<= br> > the draft suggests that demultiplexing MUST be based on some
> combination of other fields which MUST include the interface
> information of the member link. That assumes that systems are aware of=
> what interface the BFD packet came on. That is not always the case, an= d
> in a global label/IP space, systems do not have to know the physical
Can you explain the scenario where you think its not possible for a s= ystem to know the ifindex of the IP interface over which an incoming packet= arrived?

> link traffic came on. I am struggling to suggest an alternative, but > would like to see the issue addressed particularly since it is a MUST.=
>
> Same is true for the procedure for the reception of BFD control packet=
> and its verification of the interface that it came on.

I think youre missing something because we already have 3 interoperab= le implementations of this draft. Clearly, those implementations were able = to identify the IP interface over which the uBFD packet arrived.

Cheers, Manav

>
> On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote= :
>
> > Support
> >
> > -----Original Message-----
> > From: rtg-bfd-bounces= @ietf.org [mailto:rtg-bfd-b= ounces@ietf.org] On
> Behalf Of Jeffrey Haas
> > Sent: Friday, October 25, 2013 12:45 AM
> > To: rtg-bfd@ietf.org
> > Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends=
> November 8
> >
> > This email is to initiate working group last call on the BFD on L= ink
> Aggregate Group Interfaces document:
> >
> > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01<= br> > >
> > The last call will complete on November 8, the end of IETF week.<= br> > Time will be available during the Vancouver IETF BFD session to discus= s
> last call comments.
> >
> > Nobo Akiya will be serving as document shepherd (RFC 4858) for th= is
> WGLC.
> >
> > Due to the small nature of the BFD working group and the fact tha= t
> both working group chairs have contributed to this document, we have > gotten Carlos Pignataro (cpignat= a@cisco.com) to volunteer to serve as
> an independent party to gauge working group consensus.
> >
> > In order to facilitate the transparency of this WGLC, please reme= mber
> to send all comments to the working group mailing list.
> >
> > IPR declarations have been filed against this draft and the docum= ent
> authors and contributors have been polled for any further IPR. =A0Curr= ent
> IPR declarations may be seen at the following link:
> >
> >
> http://datatracker.ietf.org/ipr/sea= rch/?option=3Ddocument_search&id=3Ddraft
> -ietf-bfd-on-lags
> >
> > If you are aware of additional IPR against this document please > declare so, per the IETF Note Well.
> >
> > Finally, the IEEE has expressed interest in the disposition of th= is
> draft.
> > They will likely provide additional commentary, if any, via the I= ETF
> liaison process. =A0This process will likely happen after WGLC conclud= es.
> Depending on their feedback, WGLC may re-open to address their
> concerns.
> >
> > -- Jeff (for the chairs)
>
> Mahesh Jethanandani
> mjethanandani@gmail.com=
>
>




--
=
Mahesh Jethanandani
mjethanandani@gmail.com
--089e013cbc8c0c1a1704e9e9d5cc-- From manav.bhatia@alcatel-lucent.com Tue Oct 29 21:11:05 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9248D11E831C for ; Tue, 29 Oct 2013 21:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USCNyQF5sGdt for ; Tue, 29 Oct 2013 21:10:59 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D4AFF11E8328 for ; Tue, 29 Oct 2013 21:10:57 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9U4At7U010111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Oct 2013 23:10:55 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9U4AtR2026919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 00:10:55 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 Oct 2013 00:10:54 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 30 Oct 2013 12:10:51 +0800 From: "Bhatia, Manav (Manav)" To: Mahesh Jethanandani Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO1QKAul1Por/YwEednDQ+yn8RipoMnQrw Date: Wed, 30 Oct 2013 04:10:51 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 04:11:05 -0000 Mahesh, > The fundamental issue is that the proposal requires BFD protocol to rely = on=20 > information that is not carried in the frame itself. Unless by interface = check=20 That's what happens with most protocols. How do you identify the ingress IP= interface for an IP packet that came from a router multiple hops away. You= will have to go beyond the IP payload to associate this packet to an ingre= ss interface. > you mean check against IP address. I do not know of many protocols that r= equire=20 > one to validate/use information that is not part of the frame itself. Pro= tocols that I don't understand why you say this. The uBFD packet carries the dest IP th= at's bound to you. You use this information (i.e. the information carried i= n the frame) + some hints from the data plane to determine whether you need= to act on it or not. > have stood the test of time, like TCP, do not look beyond their own layer= s in the frame=20 > for validation of a frame. Even if we have breached the OSI layer, at lea= st we have=20 > restricted ourselves to looking at what is in the frame. This happens all the time. Multicast often takes hints from the data plane = before triggering events in the control plane (pruning the RPT, sending Reg= ister Stop messages, sending ASSERTs, etc). > The second issue as I highlighted is that there is an assumption that sys= tems carry interface=20 > information up to the protocol itself for it to validate/use the informat= ion. Again, I assume you mean=20 > the check will be against the physical interface and not the IP address. = That as I mentioned is a=20 > huge assumption. There is no precedence for this. Isnt this an implementation specific issue? You can, as you suggest later i= n your email, use the dest MAC. > There are couple of ways to solve the problem. > > One way would be to use the IP address on the individual member link to m= ap a packet=20 > to a BFD session running on a member link. When the initial BFD frame is = received with=20 > your discriminator as zero, you would use the destination IP address cont= ained in the=20 > packet to figure out which link the packet was received on. The same woul= d be true of=20 > validation of frame. This will not work for unnumbered interfaces. > > The other would be use the individual link MAC address as a way to co-rel= ate a BFD packet to=20 > a particular link both to set up a BFD session (when the discriminator is= zero) and for future validation=20 This is precisely what I had meant by this being an implementation specific= issue. Your implementation can always look at the dest MAC to figure out t= he link that the packet arrived on. It doesn't make sense to explicitly sta= te this in the draft since this is an implementation specific issue. There = are several devices that may use a chassis MAC address and MAY not allocate= a unique MAC per link. > of the frame (to a particular link). This would mean that we cannot use t= he multicast address to send the BFD frame. > > How the IP/MAC address is collected and setup is beyond the scope of this= document. Cheers, Manav On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) wrote: Hi Mahesh, This draft only talks about BFD sessions between directly connected boxes. > For initial DOWN BFD packet, where the Your Discriminator field is 0, > the draft suggests that demultiplexing MUST be based on some > combination of other fields which MUST include the interface > information of the member link. That assumes that systems are aware of > what interface the BFD packet came on. That is not always the case, and > in a global label/IP space, systems do not have to know the physical Can you explain the scenario where you think its not possible for a system = to know the ifindex of the IP interface over which an incoming packet arriv= ed? > link traffic came on. I am struggling to suggest an alternative, but > would like to see the issue addressed particularly since it is a MUST. > > Same is true for the procedure for the reception of BFD control packet > and its verification of the interface that it came on. I think youre missing something because we already have 3 interoperable imp= lementations of this draft. Clearly, those implementations were able to ide= ntify the IP interface over which the uBFD packet arrived. Cheers, Manav > > On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote: > > > Support > > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > > Sent: Friday, October 25, 2013 12:45 AM > > To: rtg-bfd@ietf.org > > Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends > November 8 > > > > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: > > > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > > > The last call will complete on November 8, the end of IETF week. > Time will be available during the Vancouver IETF BFD session to discuss > last call comments. > > > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this > WGLC. > > > > Due to the small nature of the BFD working group and the fact that > both working group chairs have contributed to this document, we have > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as > an independent party to gauge working group consensus. > > > > In order to facilitate the transparency of this WGLC, please remember > to send all comments to the working group mailing list. > > > > IPR declarations have been filed against this draft and the document > authors and contributors have been polled for any further IPR. =A0Current > IPR declarations may be seen at the following link: > > > > > http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft > -ietf-bfd-on-lags > > > > If you are aware of additional IPR against this document please > declare so, per the IETF Note Well. > > > > Finally, the IEEE has expressed interest in the disposition of this > draft. > > They will likely provide additional commentary, if any, via the IETF > liaison process. =A0This process will likely happen after WGLC concludes. > Depending on their feedback, WGLC may re-open to address their > concerns. > > > > -- Jeff (for the chairs) > > Mahesh Jethanandani > mjethanandani@gmail.com > > --=20 Mahesh Jethanandani mjethanandani@gmail.com From marc@sniff.de Tue Oct 29 23:00:24 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E402911E8216 for ; Tue, 29 Oct 2013 23:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUtD0UelXoFi for ; Tue, 29 Oct 2013 23:00:24 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C886D21F9CEA for ; Tue, 29 Oct 2013 23:00:22 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D3A322AA0F; Wed, 30 Oct 2013 06:00:14 +0000 (GMT) Date: Tue, 29 Oct 2013 23:00:13 -0700 From: Marc Binderberger To: Carlos Pignataro (cpignata) Message-ID: <20131029230013911086.c2ab6370@sniff.de> In-Reply-To: <95067C434CE250468B77282634C96ED33363277B@xmb-aln-x02.cisco.com> References: <20131024191431.GO17538@pfrc> <95067C434CE250468B77282634C96ED33363277B@xmb-aln-x02.cisco.com> Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 06:00:25 -0000 Hello Carlos, ah thanks! Okay, RFC 5342 is now RFC 7042 and I have a reference to it, to silence idnit (gee, it's just an informational reference! ...) : ----snip----snap----snip----snap---- 7. IANA Considerations IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see [RFC7042]) as well as UDP port 6784 for UDP encapsulated micro BFD sessions. ----snip----snap----snip----snap---- Will upload within the next 24 hours (unless I receive emails not to :-) Regards, Marc On Tue, 29 Oct 2013 12:18:33 +0000, Carlos Pignataro (cpignata) wrote: > [as an individual] > > Hi, > > I've followed this document and have also read the current version > under WGLC. I support its publication as it solves a real problem and > is very comprehensively written. > > There are one or two small nits (broken citations/references) that > ought to be fixed: > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bfd-on-lags-01.txt > > Thanks, > > -- Carlos. > > On Oct 24, 2013, at 3:14 PM, Jeffrey Haas wrote: > >> This email is to initiate working group last call on the BFD on Link >> Aggregate Group Interfaces document: >> >> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >> >> The last call will complete on November 8, the end of IETF week. Time will >> be available during the Vancouver IETF BFD session to discuss last call >> comments. >> >> Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. >> >> Due to the small nature of the BFD working group and the fact that both >> working group chairs have contributed to this document, we have gotten >> Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an >> independent party to gauge working group consensus. >> >> In order to facilitate the transparency of this WGLC, please remember to >> send all comments to the working group mailing list. >> >> IPR declarations have been filed against this draft and the document >> authors >> and contributors have been polled for any further IPR. Current IPR >> declarations may be seen at the following link: >> >> http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-bfd-on-lags >> >> If you are aware of additional IPR against this document please >> declare so, per >> the IETF Note Well. >> >> Finally, the IEEE has expressed interest in the disposition of this draft. >> They will likely provide additional commentary, if any, via the IETF >> liaison >> process. This process will likely happen after WGLC concludes. Depending >> on their feedback, WGLC may re-open to address their concerns. >> >> -- Jeff (for the chairs) > From marc@sniff.de Tue Oct 29 23:22:50 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3DB21E80DB for ; Tue, 29 Oct 2013 23:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4oJQU+NB0nw for ; Tue, 29 Oct 2013 23:22:50 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A9921E8095 for ; Tue, 29 Oct 2013 23:22:45 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CDE232AA0F; Wed, 30 Oct 2013 06:22:40 +0000 (GMT) Date: Tue, 29 Oct 2013 23:22:39 -0700 From: Marc Binderberger To: "Bhatia, Manav (Manav)" , Mahesh Jethanandani Message-ID: <20131029232239771745.d73bd844@sniff.de> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 06:22:51 -0000 Hello Mahesh and Manav, I share some non-understanding with Manav. The part ... > The fundamental issue is that the proposal requires BFD protocol to rely on > information that is not carried in the frame itself ... didn't make much sense to me either. Can you explain? I can guess that this first point is the same as the second point: how to get the interface information? We also do not make the assumption that the internal IP API is carrying interface information. Actually at least one vendor has exactly the situation of clearly separated L2 and L3 APIs on one of it's platforms and can implement the draft nevertheless. In other words what you see as a problem isn't one. (implementation hint: binding of MAC API per interface) Regards, Marc On Wed, 30 Oct 2013 04:10:51 +0000, Bhatia, Manav (Manav) wrote: > Mahesh, > >> The fundamental issue is that the proposal requires BFD protocol to >> rely on >> information that is not carried in the frame itself. Unless by >> interface check > > That's what happens with most protocols. How do you identify the > ingress IP interface for an IP packet that came from a router > multiple hops away. You will have to go beyond the IP payload to > associate this packet to an ingress interface. > >> you mean check against IP address. I do not know of many protocols >> that require >> one to validate/use information that is not part of the frame >> itself. Protocols that > > I don't understand why you say this. The uBFD packet carries the dest > IP that's bound to you. You use this information (i.e. the > information carried in the frame) + some hints from the data plane to > determine whether you need to act on it or not. > >> have stood the test of time, like TCP, do not look beyond their own >> layers in the frame >> for validation of a frame. Even if we have breached the OSI layer, >> at least we have >> restricted ourselves to looking at what is in the frame. > > This happens all the time. Multicast often takes hints from the data > plane before triggering events in the control plane (pruning the RPT, > sending Register Stop messages, sending ASSERTs, etc). > >> The second issue as I highlighted is that there is an assumption >> that systems carry interface >> information up to the protocol itself for it to validate/use the >> information. Again, I assume you mean >> the check will be against the physical interface and not the IP >> address. That as I mentioned is a >> huge assumption. There is no precedence for this. > > Isnt this an implementation specific issue? You can, as you suggest > later in your email, use the dest MAC. > >> There are couple of ways to solve the problem. >> >> One way would be to use the IP address on the individual member link >> to map a packet >> to a BFD session running on a member link. When the initial BFD >> frame is received with >> your discriminator as zero, you would use the destination IP address >> contained in the >> packet to figure out which link the packet was received on. The same >> would be true of >> validation of frame. This will not work for unnumbered interfaces. >> >> The other would be use the individual link MAC address as a way to >> co-relate a BFD packet to >> a particular link both to set up a BFD session (when the >> discriminator is zero) and for future validation > > This is precisely what I had meant by this being an implementation > specific issue. Your implementation can always look at the dest MAC > to figure out the link that the packet arrived on. It doesn't make > sense to explicitly state this in the draft since this is an > implementation specific issue. There are several devices that may use > a chassis MAC address and MAY not allocate a unique MAC per link. > >> of the frame (to a particular link). This would mean that we cannot >> use the multicast address to send the BFD frame. >> >> How the IP/MAC address is collected and setup is beyond the scope of >> this document. > > Cheers, Manav > > On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) > wrote: > Hi Mahesh, > > This draft only talks about BFD sessions between directly connected boxes. > >> For initial DOWN BFD packet, where the Your Discriminator field is 0, >> the draft suggests that demultiplexing MUST be based on some >> combination of other fields which MUST include the interface >> information of the member link. That assumes that systems are aware of >> what interface the BFD packet came on. That is not always the case, and >> in a global label/IP space, systems do not have to know the physical > Can you explain the scenario where you think its not possible for a > system to know the ifindex of the IP interface over which an incoming > packet arrived? > >> link traffic came on. I am struggling to suggest an alternative, but >> would like to see the issue addressed particularly since it is a MUST. >> >> Same is true for the procedure for the reception of BFD control packet >> and its verification of the interface that it came on. > I think youre missing something because we already have 3 > interoperable implementations of this draft. Clearly, those > implementations were able to identify the IP interface over which the > uBFD packet arrived. > > Cheers, Manav > >> >> On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote: >> >>> Support >>> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Jeffrey Haas >>> Sent: Friday, October 25, 2013 12:45 AM >>> To: rtg-bfd@ietf.org >>> Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends >> November 8 >>> >>> This email is to initiate working group last call on the BFD on Link >> Aggregate Group Interfaces document: >>> >>> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >>> >>> The last call will complete on November 8, the end of IETF week. >> Time will be available during the Vancouver IETF BFD session to discuss >> last call comments. >>> >>> Nobo Akiya will be serving as document shepherd (RFC 4858) for this >> WGLC. >>> >>> Due to the small nature of the BFD working group and the fact that >> both working group chairs have contributed to this document, we have >> gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as >> an independent party to gauge working group consensus. >>> >>> In order to facilitate the transparency of this WGLC, please remember >> to send all comments to the working group mailing list. >>> >>> IPR declarations have been filed against this draft and the document >> authors and contributors have been polled for any further IPR. Current >> IPR declarations may be seen at the following link: >>> >>> >> http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft >> -ietf-bfd-on-lags >>> >>> If you are aware of additional IPR against this document please >> declare so, per the IETF Note Well. >>> >>> Finally, the IEEE has expressed interest in the disposition of this >> draft. >>> They will likely provide additional commentary, if any, via the IETF >> liaison process. This process will likely happen after WGLC concludes. >> Depending on their feedback, WGLC may re-open to address their >> concerns. >>> >>> -- Jeff (for the chairs) >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> > > > > > -- > Mahesh Jethanandani > mjethanandani@gmail.com > From mjethanandani@gmail.com Thu Oct 31 10:23:40 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BABF21E80F7 for ; Thu, 31 Oct 2013 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xTRh2kDkdvN for ; Thu, 31 Oct 2013 10:23:39 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5083C21E80F4 for ; Thu, 31 Oct 2013 10:23:36 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so1948216qeb.3 for ; Thu, 31 Oct 2013 10:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JYW+6jn9+cOplSKXjPOvsShQiLPpfb6GrXs7v9lMqOU=; b=faV/ZAIWGryaX5FpS74PJtrGU6uinKUmm6zGzz61NGVlL5sWvA61b7wHI14f5Rk4v+ cXwFOzdPjNNQyMOCFVb8eLG76oH+E15wyEjVhKp3R5dncNESkyQ+5Q/wt/zbVyZV6ZCK WPbjJm1NS453yZbHCv98shAkeXSXRnzmWjmg9XUkX+ZTWJarGmgUjikz1PO1fOT3iui7 SOMpuS2BEmeMtCr8ty0IPOcJxxe0eI3vhD3SQN53Op6jDfm2tnQvmGkpBKXhuJPW97rq IxxgAHObEiziyHza13IMO/kXSl7PxFHOD+aL5p3SM8oazyTQOUxYt1ZloxRiPIoIMPQW paEA== X-Received: by 10.49.35.15 with SMTP id d15mr5798943qej.16.1383240215618; Thu, 31 Oct 2013 10:23:35 -0700 (PDT) Received: from [192.168.1.101] (108-247-126-202.lightspeed.sntcca.sbcglobal.net. [108.247.126.202]) by mx.google.com with ESMTPSA id l5sm11185669qac.12.2013.10.31.10.23.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 10:23:34 -0700 (PDT) Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Thu, 31 Oct 2013 10:23:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E4E9FDA-8DBD-40F5-A8EB-1B13B7AC0EBD@gmail.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1085) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2013 17:23:40 -0000 Manav, It is understandable that from an implementation perspective, systems = might choose to use their own methods to validate frames. RFCs generally = tend to stay clear of implementation details. Making a MUST in the = protocol for something that is not in the frame itself is new to me. How about in Section 2.2 third and fourth paragraph you drop the MUST to = a SHOULD and clarify what you mean by "interface information" to include = e.g. destination IP address or destination MAC address. So the = paragraphs would read something like this. Third paragraph: "In this case demultiplexing MUST be based on some combination of other = fields which SHOULD include the interface information of the member = link, such as destination IP address of the member link or destination = MAC address of the member link." and Fourth paragraph: "If the Your Discriminator field is non-zero and a micro BFD over LAG = session is found, the interface on which the micro BFD control packet = arrived on SHOULD correspond to the interface associated with that = session. This interface association can be in the form of destination IP = address of the member link or destination MAC address of the member = link". Best. On Oct 29, 2013, at 9:10 PM, Bhatia, Manav (Manav) wrote: > Mahesh, >=20 >> The fundamental issue is that the proposal requires BFD protocol to = rely on=20 >> information that is not carried in the frame itself. Unless by = interface check=20 >=20 > That's what happens with most protocols. How do you identify the = ingress IP interface for an IP packet that came from a router multiple = hops away. You will have to go beyond the IP payload to associate this = packet to an ingress interface. >=20 >> you mean check against IP address. I do not know of many protocols = that require=20 >> one to validate/use information that is not part of the frame itself. = Protocols that >=20 > I don't understand why you say this. The uBFD packet carries the dest = IP that's bound to you. You use this information (i.e. the information = carried in the frame) + some hints from the data plane to determine = whether you need to act on it or not. >=20 >> have stood the test of time, like TCP, do not look beyond their own = layers in the frame=20 >> for validation of a frame. Even if we have breached the OSI layer, at = least we have=20 >> restricted ourselves to looking at what is in the frame. >=20 > This happens all the time. Multicast often takes hints from the data = plane before triggering events in the control plane (pruning the RPT, = sending Register Stop messages, sending ASSERTs, etc). >=20 >> The second issue as I highlighted is that there is an assumption that = systems carry interface=20 >> information up to the protocol itself for it to validate/use the = information. Again, I assume you mean=20 >> the check will be against the physical interface and not the IP = address. That as I mentioned is a=20 >> huge assumption. There is no precedence for this. >=20 > Isnt this an implementation specific issue? You can, as you suggest = later in your email, use the dest MAC. >=20 >> There are couple of ways to solve the problem. >>=20 >> One way would be to use the IP address on the individual member link = to map a packet=20 >> to a BFD session running on a member link. When the initial BFD frame = is received with=20 >> your discriminator as zero, you would use the destination IP address = contained in the=20 >> packet to figure out which link the packet was received on. The same = would be true of=20 >> validation of frame. This will not work for unnumbered interfaces. >>=20 >> The other would be use the individual link MAC address as a way to = co-relate a BFD packet to=20 >> a particular link both to set up a BFD session (when the = discriminator is zero) and for future validation=20 >=20 > This is precisely what I had meant by this being an implementation = specific issue. Your implementation can always look at the dest MAC to = figure out the link that the packet arrived on. It doesn't make sense to = explicitly state this in the draft since this is an implementation = specific issue. There are several devices that may use a chassis MAC = address and MAY not allocate a unique MAC per link. >=20 >> of the frame (to a particular link). This would mean that we cannot = use the multicast address to send the BFD frame. >>=20 >> How the IP/MAC address is collected and setup is beyond the scope of = this document. >=20 > Cheers, Manav >=20 > On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) = wrote: > Hi Mahesh, >=20 > This draft only talks about BFD sessions between directly connected = boxes. >=20 >> For initial DOWN BFD packet, where the Your Discriminator field is 0, >> the draft suggests that demultiplexing MUST be based on some >> combination of other fields which MUST include the interface >> information of the member link. That assumes that systems are aware = of >> what interface the BFD packet came on. That is not always the case, = and >> in a global label/IP space, systems do not have to know the physical > Can you explain the scenario where you think its not possible for a = system to know the ifindex of the IP interface over which an incoming = packet arrived? >=20 >> link traffic came on. I am struggling to suggest an alternative, but >> would like to see the issue addressed particularly since it is a = MUST. >>=20 >> Same is true for the procedure for the reception of BFD control = packet >> and its verification of the interface that it came on. > I think youre missing something because we already have 3 = interoperable implementations of this draft. Clearly, those = implementations were able to identify the IP interface over which the = uBFD packet arrived. >=20 > Cheers, Manav >=20 >>=20 >> On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) = wrote: >>=20 >>> Support >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Jeffrey Haas >>> Sent: Friday, October 25, 2013 12:45 AM >>> To: rtg-bfd@ietf.org >>> Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends >> November 8 >>>=20 >>> This email is to initiate working group last call on the BFD on Link >> Aggregate Group Interfaces document: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >>>=20 >>> The last call will complete on November 8, the end of IETF week. >> Time will be available during the Vancouver IETF BFD session to = discuss >> last call comments. >>>=20 >>> Nobo Akiya will be serving as document shepherd (RFC 4858) for this >> WGLC. >>>=20 >>> Due to the small nature of the BFD working group and the fact that >> both working group chairs have contributed to this document, we have >> gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as >> an independent party to gauge working group consensus. >>>=20 >>> In order to facilitate the transparency of this WGLC, please = remember >> to send all comments to the working group mailing list. >>>=20 >>> IPR declarations have been filed against this draft and the document >> authors and contributors have been polled for any further IPR. = Current >> IPR declarations may be seen at the following link: >>>=20 >>>=20 >> = http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t >> -ietf-bfd-on-lags >>>=20 >>> If you are aware of additional IPR against this document please >> declare so, per the IETF Note Well. >>>=20 >>> Finally, the IEEE has expressed interest in the disposition of this >> draft. >>> They will likely provide additional commentary, if any, via the IETF >> liaison process. This process will likely happen after WGLC = concludes. >> Depending on their feedback, WGLC may re-open to address their >> concerns. >>>=20 >>> -- Jeff (for the chairs) >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >=20 >=20 >=20 >=20 > --=20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com From jhaas@slice.pfrc.org Thu Oct 31 15:20:22 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A3921F9F20 for ; Thu, 31 Oct 2013 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZe3ttmvBT+8 for ; Thu, 31 Oct 2013 15:20:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6659E11E8254 for ; Thu, 31 Oct 2013 15:20:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 08497C3A3; Thu, 31 Oct 2013 18:20:18 -0400 (EDT) Date: Thu, 31 Oct 2013 18:20:17 -0400 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Message-ID: <20131031222017.GA4446@pfrc> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2013 22:20:23 -0000 For Mahesh, On Wed, Oct 30, 2013 at 04:10:51AM +0000, Bhatia, Manav (Manav) wrote: > > have stood the test of time, like TCP, do not look beyond their own layers in the frame > > for validation of a frame. Even if we have breached the OSI layer, at least we have > > restricted ourselves to looking at what is in the frame. > > This happens all the time. Multicast often takes hints from the data plane before triggering events in the control plane (pruning the RPT, sending Register Stop messages, sending ASSERTs, etc). I want to strongly support this point since it seems to be the big item of contention here. IP implementations have been able to tell what interface datagram protocols come in for a rather long time. If you were to base your argument largely upon this point, you'll have to throw out a large chunk of deployed multicast protocols. :-) FYI: http://linux.die.net/man/7/ip - see IP_PKTINFO > > The other would be use the individual link MAC address as a way to co-relate a BFD packet to > > a particular link both to set up a BFD session (when the discriminator is zero) and for future validation > > This is precisely what I had meant by this being an implementation specific issue. Your implementation can always look at the dest MAC to figure out the link that the packet arrived on. It doesn't make sense to explicitly state this in the draft since this is an implementation specific issue. There are several devices that may use a chassis MAC address and MAY not allocate a unique MAC per link. The draft effectively says "figure out what interface it came in on". If a given implementation of an IP stack has deficiencies compared to others, there are options. The real question is whether the text is clear enough about this point. -- Jeff From mjethanandani@gmail.com Thu Oct 31 19:10:50 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD84411E8294 for ; Thu, 31 Oct 2013 19:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJLSz0aeNKZV for ; Thu, 31 Oct 2013 19:10:50 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2C97A11E8291 for ; Thu, 31 Oct 2013 19:10:49 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f13so2854725vbg.11 for ; Thu, 31 Oct 2013 19:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NXHj417bbAtmuGpz3L4lQyk9z7NFogIXFJWBFD8k+ZI=; b=zhub4e2f32XLTNJKjxeTbQ3rz2kBZwqlgrnIEnI9w3/n7K2Prev9lTA6Y4/I0weMU3 CFofn9J7Aw1avHQGCTwnlLj+ywhwy9ZNBJDp4xrU5NC4pS0dBPYY/qpyP8Iamj6RuLaF VcBUcvKPZuIcClWX5iwC4bwm4t0+jQMZUszqpPPWyKDyGcwdgd2ll/emhJ4qEMXapflV R3b/T3CRG1Mctgs7aiZIM7HxXD0elWPfg0ESG9aVbmrtU2zq1cMlQrMDgfil/YUvdoxI azeXMzCDkqrM/T+eP2NGM9VDvjtuN3qARWJunfGNSHwaiyYvgy6RS5VxqmCZvhKSR72Q Kt3w== MIME-Version: 1.0 X-Received: by 10.220.250.4 with SMTP id mm4mr350722vcb.47.1383271848502; Thu, 31 Oct 2013 19:10:48 -0700 (PDT) Received: by 10.53.13.133 with HTTP; Thu, 31 Oct 2013 19:10:48 -0700 (PDT) In-Reply-To: <20131031222017.GA4446@pfrc> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20131031222017.GA4446@pfrc> Date: Thu, 31 Oct 2013 19:10:48 -0700 Message-ID: Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 From: Mahesh Jethanandani To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e0160c2dc286a5604ea141383 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2013 02:10:51 -0000 --089e0160c2dc286a5604ea141383 Content-Type: text/plain; charset=ISO-8859-1 Jeff, My e-mail editor behaves funny so look for comment starting with [mj] On Thu, Oct 31, 2013 at 3:20 PM, Jeffrey Haas wrote: > For Mahesh, > > On Wed, Oct 30, 2013 at 04:10:51AM +0000, Bhatia, Manav (Manav) wrote: > > > have stood the test of time, like TCP, do not look beyond their own > layers in the frame > > > for validation of a frame. Even if we have breached the OSI layer, at > least we have > > > restricted ourselves to looking at what is in the frame. > > > > This happens all the time. Multicast often takes hints from the data > plane before triggering events in the control plane (pruning the RPT, > sending Register Stop messages, sending ASSERTs, etc). > > I want to strongly support this point since it seems to be the big item of > contention here. IP implementations have been able to tell what interface > datagram protocols come in for a rather long time. > > If you were to base your argument largely upon this point, you'll have to > throw out a large chunk of deployed multicast protocols. :-) > > FYI: > http://linux.die.net/man/7/ip - see IP_PKTINFO > > > The other would be use the individual link MAC address as a way to > co-relate a BFD packet to > > > a particular link both to set up a BFD session (when the discriminator > is zero) and for future validation > > > > This is precisely what I had meant by this being an implementation > specific issue. Your implementation can always look at the dest MAC to > figure out the link that the packet arrived on. It doesn't make sense to > explicitly state this in the draft since this is an implementation specific > issue. There are several devices that may use a chassis MAC address and MAY > not allocate a unique MAC per link. > > The draft effectively says "figure out what interface it came in on". If a > given implementation of an IP stack has deficiencies compared to others, > there are options. The real question is whether the text is clear enough > about this point. > [mj] My last e-mail effectively suggests just that. If the draft says, figure out for yourself which member link a particular BFD frame came on, it would be fine. It is the implication (and where the text could be more clear), that it is the ifIndex that the system MUST match against, is where I had a problem. How systems map the frame to a member link is an implementation level detail which is outside the scope of this draft. I suggested some text, but it is just that. > -- Jeff > -- Mahesh Jethanandani mjethanandani@gmail.com --089e0160c2dc286a5604ea141383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jeff,

My e-mail editor behaves funny so= look for comment starting with [mj]

On Thu, Oct 31, 2013 at 3:20 PM, Jeffrey Haas = <j= haas@pfrc.org> wrote:
For Mahesh,

On Wed, Oct 30, 2013 at 04:10:51AM +0000, Bhatia, Manav (Manav) wrote:
> > have stood the test of time, like TCP, do not look beyond their o= wn layers in the frame
> > for validation of a frame. Even if we have breached the OSI layer= , at least we have
> > restricted ourselves to looking at what is in the frame.
>
> This happens all the time. Multicast often takes hints from the data p= lane before triggering events in the control plane (pruning the RPT, sendin= g Register Stop messages, sending ASSERTs, etc).

I want to strongly support this point since it seems to be the big it= em of
contention here. =A0IP implementations have been able to tell what interfac= e
datagram protocols come in for a rather long time.

If you were to base your argument largely upon this point, you'll have = to
throw out a large chunk of deployed multicast protocols. :-)

FYI:
http://linux.di= e.net/man/7/ip - see IP_PKTINFO

> > The other would be use the individual link MAC address as a way t= o co-relate a BFD packet to
> > a particular link both to set up a BFD session (when the discrimi= nator is zero) and for future validation
>
> This is precisely what I had meant by this being an implementation spe= cific issue. Your implementation can always look at the dest MAC to figure = out the link that the packet arrived on. It doesn't make sense to expli= citly state this in the draft since this is an implementation specific issu= e. There are several devices that may use a chassis MAC address and MAY not= allocate a unique MAC per link.

The draft effectively says "figure out what interface it came in= on". =A0If a
given implementation of an IP stack has deficiencies compared to others, there are options. =A0The real question is whether the text is clear enough=
about this point.

[mj] My last e-mail e= ffectively suggests just that. If the draft says, figure out for yourself w= hich member link a particular BFD frame came on, it would be fine. It is th= e implication (and where the text could be more clear), that it is the ifIn= dex that the system MUST match against, is where I had a problem.

How systems map the frame to a member link is an implem= entation level detail which is outside the scope of this draft.
<= br>
I suggested some text, but it is just that.


-- Jeff



--
Mahesh Jethanandani
mjethanandani@gmail.com
--089e0160c2dc286a5604ea141383-- From marc@sniff.de Thu Oct 31 22:16:08 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5C21F9D19 for ; Thu, 31 Oct 2013 22:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXfMmUXKuWoZ for ; Thu, 31 Oct 2013 22:16:06 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD4911E81A3 for ; Thu, 31 Oct 2013 22:16:01 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 9BAC22AA0F; Fri, 1 Nov 2013 05:15:58 +0000 (GMT) Date: Thu, 31 Oct 2013 22:15:57 -0700 From: Marc Binderberger To: Mahesh Jethanandani Message-ID: <20131031221557769087.2dd1be73@sniff.de> In-Reply-To: References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E4F2A93@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20131031222017.GA4446@pfrc> Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2013 05:16:08 -0000 Hello Mahesh et al., from the draft, section 2.2: The demultiplexing of a received BFD packet is solely based on the Your Discriminator field, if this field is nonzero. For the initial Down BFD packets of a BFD session this value MAY be zero. In this case demultiplexing MUST be based on some combination of other fields which MUST include the interface information of the member link. The procedure for the Reception of BFD Control Packets in Section 6.8.6 of [RFC5880] is amended as follows for per LAG member link micro BFD sessions: "If the Your Discriminator field is non-zero and a micro BFD over LAG session is found, the interface on which the micro BFD control packet arrived on MUST correspond to the interface associated with that session." And that's it pretty much what we are saying. Fairly generic. What this "interface information" is we don't say because this may differ from implementation to implementation - and the details are not relevant for this specification. Don't get me wrong, you had a question and you got an answer. But I don't see anything to change in the draft. Regards, Marc On Thu, 31 Oct 2013 19:10:48 -0700, Mahesh Jethanandani wrote: > Jeff, > > My e-mail editor behaves funny so look for comment starting with [mj] > > > On Thu, Oct 31, 2013 at 3:20 PM, Jeffrey Haas wrote: >> For Mahesh, >> >> On Wed, Oct 30, 2013 at 04:10:51AM +0000, Bhatia, Manav (Manav) wrote: >>> > have stood the test of time, like TCP, do not look beyond their >> own layers in the frame >>> > for validation of a frame. Even if we have breached the OSI >> layer, at least we have >>> > restricted ourselves to looking at what is in the frame. >>> >>> This happens all the time. Multicast often takes hints from the >> data plane before triggering events in the control plane (pruning >> the RPT, sending Register Stop messages, sending ASSERTs, etc). >> >> I want to strongly support this point since it seems to be the big item of >> contention here. IP implementations have been able to tell what interface >> datagram protocols come in for a rather long time. >> >> If you were to base your argument largely upon this point, you'll have to >> throw out a large chunk of deployed multicast protocols. :-) >> >> FYI: >> http://linux.die.net/man/7/ip - see IP_PKTINFO >> >>> > The other would be use the individual link MAC address as a way >> to co-relate a BFD packet to >>> > a particular link both to set up a BFD session (when the >> discriminator is zero) and for future validation >>> >>> This is precisely what I had meant by this being an implementation >> specific issue. Your implementation can always look at the dest MAC >> to figure out the link that the packet arrived on. It doesn't make >> sense to explicitly state this in the draft since this is an >> implementation specific issue. There are several devices that may >> use a chassis MAC address and MAY not allocate a unique MAC per link. >> >> The draft effectively says "figure out what interface it came in on". If a >> given implementation of an IP stack has deficiencies compared to others, >> there are options. The real question is whether the text is clear enough >> about this point. > > [mj] My last e-mail effectively suggests just that. If the draft > says, figure out for yourself which member link a particular BFD > frame came on, it would be fine. It is the implication (and where the > text could be more clear), that it is the ifIndex that the system > MUST match against, is where I had a problem. > > How systems map the frame to a member link is an implementation level > detail which is outside the scope of this draft. > > I suggested some text, but it is just that. > >> >> -- Jeff > > > > -- > Mahesh Jethanandani > mjethanandani@gmail.com From mjethanandani@gmail.com Thu Oct 31 23:10:13 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DDA21E814A for ; Thu, 31 Oct 2013 23:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqkT2jCtGdwT for ; Thu, 31 Oct 2013 23:10:13 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3586B21E80AF for ; Thu, 31 Oct 2013 23:10:13 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so6922501iec.29 for ; Thu, 31 Oct 2013 23:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TTMaP/QMitVby4mFAg3ovW+69DkKNDB7/egkdjy18cY=; b=Jky8w0nt40f59ZbgweUOnM2rMheaPQYwJ3Efb1zJ501eonsJ0IiLSKo5A5UMKtU5SU ZAhMQC77l8WcXhp3o0JIdgl7/9tEbIBn4+FJE7sXhAVYv329H5j4Cs5dMuDuTKADvSxr K+7ZshCRiFX/RYEJ7gskPVGSMBCc97tepvUeLBPjdEbuGqKScwobt44xpkZ7JmJ8j1cE r/FpHLB08ERKCXIB9wXHUeUW34MThHvpQ9Y8aoT7tFf4aPlNSEB5JmH/w/tNBYPf6wil 4onY5t2sWJaAVl+fTM35VXbhbBMSc3U/hx0bahL7tQCSinlejTc13ytgAWmbTnC9IYDI 877w== X-Received: by 10.50.107.70 with SMTP id ha6mr954635igb.60.1383286212699; Thu, 31 Oct 2013 23:10:12 -0700 (PDT) Received: from [192.168.1.101] (108-247-126-202.lightspeed.sntcca.sbcglobal.net. [108.247.126.202]) by mx.google.com with ESMTPSA id p7sm2710217iga.3.2013.10.31.23.10.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 23:10:12 -0700 (PDT) Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Thu, 31 Oct 2013 23:10:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: Marc Binderberger X-Mailer: Apple Mail (2.1085) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2013 06:10:14 -0000 Marc, I do not know about you, but when I read interface there are specific = implications in my mind of what it means. To a certain extent I can see = that is in this response from Manav. It means something very specific. On Oct 27, 2013, at 4:37 AM, Bhatia, Manav (Manav) wrote: > Can you explain the scenario where you think its not possible for a = system to know the ifindex of the IP interface over which an incoming = packet arrived? My point is that if you believe that by "interface information" you do = not necessarily mean the interface (ifIndex) itself or that it is a = fairly generic reference to an identification of a member link of LAG, = then just say so. Or better still, say what it should mean. What is = wrong with being more clear? If I mis-read what was meant, so will = others. Cheers. Mahesh Jethanandani mjethanandani@gmail.com