From nobody Tue Mar 4 16:44:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50D81A002F for ; Tue, 4 Mar 2014 16:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsyAhcM-RGYf for ; Tue, 4 Mar 2014 16:44:42 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 19C271A000A for ; Tue, 4 Mar 2014 16:44:41 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id x48so342467wes.21 for ; Tue, 04 Mar 2014 16:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=2f15Y1IoupduBGBWjQm5qeWc2wQskAgwe7t+mrLADfM=; b=d8OxqYBImw6B3E6RH1H+gD93NPfRd15gU/xilmYT77FhutdTx3mxYw4DopCphKNjD2 b7izQ11GcSEg6zzHElda0y9EB2URk3cDQHjlnSZFsgg9Mn5Pa2t0C79ADF+rzyvPKEt9 Q9opPuaa4NvBzVEMmaR9aZpjcwAD9Cg7lVJ6Q3GdLYvoW9iAZOYPUtC2zKfjCCFwTgS2 CL/CQw20OOH7gbH3IqQNHRcPcMKuI92/1+TIDHdDQF2HbFAHdFAJbSmEbhIQj5c1xekT 0PflauyLsCAuRKUMPayVwCrx5aW/G/I8e4Nb8W6A0KViiEKYnxl3F0PNq8UF4rcWwrVI lpSQ== X-Received: by 10.194.203.200 with SMTP id ks8mr3574511wjc.61.1393980278282; Tue, 04 Mar 2014 16:44:38 -0800 (PST) Received: from [130.129.27.251] ([130.129.27.251]) by mx.google.com with ESMTPSA id jw4sm2923395wjc.20.2014.03.04.16.44.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 16:44:37 -0800 (PST) Message-ID: <53167375.1020902@gmail.com> Date: Tue, 04 Mar 2014 16:44:37 -0800 From: "Jethanandani, Mahesh" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "BFD WG" Subject: Our BFD draft in MPLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9PT_W602w0Jfcy6K7ZUFFpEW1Dg X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 00:44:44 -0000 We do not have a BFD session in London. But I will be presenting some findings on the threats that have been identified for BFD, what we are proposing from a security perspective and the impact it has to the MPLS WG on Thursday. If this is something that interests you, you might want to tune into the MPLS WG session on Thursday. http://tools.ietf.org/html/draft-ietf-karp-bfd-analysis-01 -- Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Mar 4 19:31:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84CA1A0126 for ; Tue, 4 Mar 2014 19:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd-szYEuXFn3 for ; Tue, 4 Mar 2014 19:31:02 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 75C751A01D2 for ; Tue, 4 Mar 2014 19:31:02 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id uo5so465678pbc.38 for ; Tue, 04 Mar 2014 19:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:content-type; bh=QEcLl7eHImRfgNQNT3FgDAJcUeKGVvv5DPQjwaT1ZXQ=; b=fzqpYlry7mnsUcvbsgN0T5//fAj2bZAV8cvyWgRdgyJr8y70EOH05gZUV9upoCVxwu pgyWymfAq2oNG6E4D7/EQeq648BDUVLsgx716w3GgH7QGO+/at7au0Z0rG2kYZg0OIC2 4vxVRwHQFnB6O7i8qWKPH7NT0gQO11+N6MQ2/jm1xfqOgvbSv+8j6XfC1F2JY3j0pn8k yrzVaD9FN3PW36ZfZ5CbfB41JBzsaaQwzF1TmrJYWYzKAlQ81Lmh0QqoUC0ULPeZKOPQ Fk03JqL0SfZivta6KuTBIfYGELSPxVUupw7hGObuV5jCht6VBOmt+Qiel86adm1jWYH7 PiWA== X-Received: by 10.68.129.5 with SMTP id ns5mr3669862pbb.147.1393990259133; Tue, 04 Mar 2014 19:30:59 -0800 (PST) Received: from [223.227.202.220] ([223.227.202.220]) by mx.google.com with ESMTPSA id vf7sm2540141pbc.5.2014.03.04.19.30.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Mar 2014 19:30:57 -0800 (PST) Message-ID: <53169a71.e7ed440a.5c5c.ffff8ccc@mx.google.com> MIME-Version: 1.0 To: "Jethanandani, Mahesh" , BFD WG From: Binny Jeshan Subject: RE: Our BFD draft in MPLS WG Date: Wed, 5 Mar 2014 09:00:00 +0530 Content-Type: multipart/alternative; boundary="_1A229801-3A13-4475-BAF9-0632506EEA9D_" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/yUiKm6NTpNntIDP2_67gm_F5I4U X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 03:31:06 -0000 --_1A229801-3A13-4475-BAF9-0632506EEA9D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Interesting, also eager to know further about this.=20 Regards, Binny. Aricent India ------------------------- Sent from Nokia Lumia. -----Original Message----- From: "Jethanandani, Mahesh" Sent: =E2=80=8E05-=E2=80=8E03-=E2=80=8E2014 06:14 AM To: "BFD WG" Subject: Our BFD draft in MPLS WG We do not have a BFD session in London. But I will be presenting some=20 findings on the threats that have been identified for BFD, what we are=20 proposing from a security perspective and the impact it has to the MPLS=20 WG on Thursday. If this is something that interests you, you might want=20 to tune into the MPLS WG session on Thursday. http://tools.ietf.org/html/draft-ietf-karp-bfd-analysis-01 --=20 Mahesh Jethanandani mjethanandani@gmail.com --_1A229801-3A13-4475-BAF9-0632506EEA9D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Interesting= , also eager to know further about this.

Regards,
Binny.
Aric= ent India
-------------------------
Sent from Nokia Lumia.
From: Jethanandani, Mahesh=
Sent: =E2=80=8E05-=E2=80=8E03-=E2=80=8E2014 06:14 AM
To: BFD WGSubject: Our BFD draft in MPLS WG

We do not have= a BFD session in London. But I will be presenting some
findings on the= threats that have been identified for BFD, what we are
proposing from = a security perspective and the impact it has to the MPLS
WG on Thursday= . If this is something that interests you, you might want
to tune into = the MPLS WG session on Thursday.

http://tools.ietf.org/html/draft-ie= tf-karp-bfd-analysis-01

--
Mahesh Jethanandani
mjethanandani@= gmail.com

= --_1A229801-3A13-4475-BAF9-0632506EEA9D_-- From nobody Wed Mar 5 08:06:30 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1561A068A for ; Wed, 5 Mar 2014 08:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV87fsOoHAD1 for ; Wed, 5 Mar 2014 08:06:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B47831A03BC for ; Wed, 5 Mar 2014 08:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1551; q=dns/txt; s=iport; t=1394035581; x=1395245181; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=8ENE+lKfM6fNNJVLC6xYw2Eht0DWWwcONhaK1ugSsY4=; b=C1VJz8ec7+HnsA4uKrKw/nOJIonweRfvl0Uf94QJ6+NabagoppAiL7Os TiJYhcFw9Mi7TbD9Li7vUufWdVS1xqZm4rLFd9GZ7gZJIkTr5IhYsfTRO 19LsKvisnko9YHIei1ZI2IlvwkclV8YwLodAb8JmOIPqEbUAWnMXg/SFW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACpLF1OtJV2Z/2dsb2JhbABagmUhO1fBC4EZFnSCJwEEOj8SASoUQiYBBAENDYdxAQzOHheOIDGDK4EUBJlvkHmDLYIq X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="308246327" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 05 Mar 2014 16:06:10 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s25G690j012299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 16:06:09 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.03.0123.003; Wed, 5 Mar 2014 10:06:08 -0600 From: "Nobo Akiya (nobo)" To: "Sam Aldrin (sam.aldrin@gmail.com)" , "Bhatia, Manav (Manav) (manav.bhatia@alcatel-lucent.com)" , "Gregory Mirsky (gregory.mirsky@ericsson.com)" , "Nagendra Kumar Nainar (naikumar)" , "satoru.matsushima@g.softbank.co.jp" Subject: Possible addition to S-BFD use-case draft? Thread-Topic: Possible addition to S-BFD use-case draft? Thread-Index: Ac84hmdERRnvRqtWQuCLjKvrLSpA0Q== Date: Wed, 5 Mar 2014 16:06:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qQEDeP0s6URkmO5X_c_C8JD-VL0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 16:06:28 -0000 Hi S-BFD use-case draft authors, Document reads nicely, thank you! I'd like to propose a possible addition to the S-BFD use-case draft. BFD MPLS (RFC5884) states: [snip] If there are multiple alternate paths from an ingress LSR to an egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to determine each of these alternate paths. A BFD session SHOULD be established for each alternate path that is discovered. [snip] Above implies that a BFD session should be bootstrapped per alternate (i.e.= ECMP) path, but RFC does not have further details no how to create/maintai= n multiple BFD MPLS sessions per FEC. Questions I have are: * How should egress de-multiplex the bootstrap request per alternate path? * If/when number of alternate paths changes or hash key changes: - how should ingress delete BFD sessions on egress? - re-bootstrapping set of sessions can be [relatively] inefficient as t= hat can consume time/resources. Alternative is to use S-BFD for multiple alternate paths for a FEC, which e= liminates the concerns raised from above questions ... and much simpler to = implement and operate. If you think this will be useful, perhaps we can add this in ... http://tools.ietf.org/html/draft-aldrin-bfd-seamless-use-case-00#section-3.= 8 or a new sub-section can be created? Of course action resulting from this multiple path failure detection is ano= ther question itself, but at least we can detect this more efficiently. -Nobo [as individual contributor] From nobody Wed Mar 5 08:06:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9971A069C for ; Wed, 5 Mar 2014 08:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ypb526QBd6K for ; Wed, 5 Mar 2014 08:06:34 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 814F41A066A for ; Wed, 5 Mar 2014 08:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3798; q=dns/txt; s=iport; t=1394035590; x=1395245190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EA7EsvA5eapOQsiKY0lV+Sk+qjScsQKIwinogEKT0QM=; b=iubNGzVLTrriTIvOorxcQ6yDiQyTr0a+APFT3vH3Iomg0NKLBLDSNg3/ zF7kzlWdeZDE51IQ6Iz+F/YNOAKjhAd+kHAVVAtlHPj8jte2/GgqndTfg Hx06PR66uiX7NKmLz6fLSz2fwI3TVB1Ee92rYEtHn5PW+a++HWSFRNXDQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFADtLF1OtJXHA/2dsb2JhbABagmUhO1EGgwS+BxmBABZ0giUBAQEEIxFDAgwEAgEIEQQBAQMCBh0DAgICMBQBCAgCBAENBQgBh3ABBwWtdKArF4EpjHcWGwcGgmk1gRQEmW+QeYMtgio X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="308221199" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 05 Mar 2014 16:06:22 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s25G6MwK019052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 16:06:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 10:06:22 -0600 From: "Nobo Akiya (nobo)" To: "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Topic: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Index: AQHPKU6nR9GbDMvL1kyrqazOoH9UkZq0m7pAgB4k6lA= Date: Wed, 5 Mar 2014 16:06:21 +0000 Message-ID: References: <20140214063317.13350.93940.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D3397E8C3@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D3397E8C3@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.212.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/r9vL_t2nMwOzzU1UGnskVxbjxZI Cc: "Samer Salam \(ssalam\)" , "Ali Sajassi \(sajassi\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 16:06:37 -0000 W2NoYWlyIGhhdCBvbl0NCg0KVGhhbmtzIGZvciBicmluZyB0aGlzIGRyYWZ0IHRvIG91ciBhdHRl bnRpb24uDQoNCkFsbCwgcGxlYXNlIHJldmlldyBhbmQgcHJvdmlkZSBjb21tZW50cy4NCg0KT25l IHBvaW50IG9mIHRoZSBkcmFmdCB3aGljaCBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgb3V0ICYgc2Vl ayBpbnB1dC9jb21tZW50cyBmcm9tIEJGRGVycyAuLi4NCg0KRHJhZnQgdXNlcyBMU1AgcGluZyB0 byBib290c3RyYXAgc2Vzc2lvbnMgb24gZWdyZXNzLCBmb3IgRVZQTiBGRUMuDQpEcmFmdCBsZWF2 ZXMgcm9vbSBmb3IgYm9vdHN0cmFwcGluZy9ydW5uaW5nIEJGRCBzZXNzaW9uIHBlciBFQ01QIHBh dGgsIGZvciBFVlBOIEZFQy4NCg0KRG8gd2Ugd2FudCB0aGVzZSB0ZXh0cyB0byByZW1haW4sIHdo aWNoIGFsbG93cyBFVlBOIGxheWVyIHRvIG1vbml0b3IgRUNNUCBwYXRocyBvZiBNUExTIGxheWVy Pw0KT3IgZG8gd2Ugd2FudCBFQ01QIG1vbml0b3IgdG8gYmUgbGVmdCBhdCBNUExTIGxheWVyPw0K DQpDb21tZW50cz8NCg0KLU5vYm8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgVmVuZ2FkYQ0KPiBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKQ0KPiBTZW50OiBGcmlkYXks IEZlYnJ1YXJ5IDE0LCAyMDE0IDY6MjUgQU0NCj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gQ2M6 IFNhbWVyIFNhbGFtIChzc2FsYW0pOyBBbGkgU2FqYXNzaSAoc2FqYXNzaSkNCj4gU3ViamVjdDog Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2 cG4tYmZkLQ0KPiAwMS50eHQNCj4gDQo+IEhlbGxvIGFsbCwNCj4gICBGWUksIHRoZSBsYXRlc3Qg cmV2aXNpb24gb2YgdGhlIGZvbGxvd2luZyBkcmFmdCBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gdGhl DQo+IG1lbWJlcnMgb2YgdGhlIEJGRCBXRyBhcyB3ZWxsLg0KPiBUaGFua3MNCj4gUHJhc2FkDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogRnJpZGF5LCBG ZWJydWFyeSAxNCwgMjAxNCAxMjowMyBQTQ0KPiBUbzogU2FtZXIgU2FsYW0gKHNzYWxhbSk7IFNh bWVyIFNhbGFtIChzc2FsYW0pOyBWZW5nYWRhIFByYXNhZA0KPiBHb3ZpbmRhbiAodmVuZ2dvdmkp OyBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpOyBBbGkgU2FqYXNzaQ0KPiAoc2Fq YXNzaSk7IEFsaSBTYWphc3NpIChzYWphc3NpKQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0NCj4gMDEudHh0DQo+ IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBu LWJmZC0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWZW5nYWRh IFByYXNhZCBHb3ZpbmRhbiBhbmQgcG9zdGVkDQo+IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+ IA0KPiBOYW1lOgkJZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZkDQo+IFJldmlzaW9uOgkw MQ0KPiBUaXRsZToJCVByb2FjdGl2ZSBmYXVsdCBkZXRlY3Rpb24gaW4gRVZQTg0KPiBEb2N1bWVu dCBkYXRlOgkyMDE0LTAyLTE0DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBh Z2VzOgkJOQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtdmdvdmluZGFuLWwydnBuLQ0KPiBldnBuLWJmZC0wMS50eHQNCj4gU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZnb3ZpbmRh bi1sMnZwbi1ldnBuLQ0KPiBiZmQvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1iZmQtMDENCj4gRGlmZjogICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXZnb3ZpbmRhbi1s MnZwbi1ldnBuLQ0KPiBiZmQtMDENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50 IHByb3Bvc2VzIGEgcHJvYWN0aXZlLCBpbi1iYW5kIG5ldHdvcmsgT0FNIG1lY2hhbmlzbQ0KPiB0 bw0KPiAgICBkZXRlY3QgY29ubmVjdGl2aXR5IGZhdWx0cyB0aGF0IGFmZmVjdCB1bmljYXN0IGFu ZCBtdWx0aS1kZXN0aW5hdGlvbg0KPiAgICBwYXRocyBpbiBhbiBFVlBOIG5ldHdvcmsuIFRoZSBt dWx0aS1kZXN0aW5hdGlvbiBwYXRocyBhcmUgdXNlZCBieQ0KPiAgICBCcm9hZGNhc3QsIHVua25v d24gVW5pY2FzdCBhbmQgTXVsdGljYXN0IChCVU0pIHRyYWZmaWMuIFRoZQ0KPiAgICBtZWNoYW5p c21zIHByb3Bvc2VkIGluIHRoZSBkcmFmdCB1c2UgdGhlIHByaW5jaXBsZXMgb2YgdGhlIHdpZGVs eQ0KPiAgICBhZG9wdGVkIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkg cHJvdG9jb2wuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Mar 5 13:49:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D563A1A0650 for ; Wed, 5 Mar 2014 13:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AhVkJY3lrTl for ; Wed, 5 Mar 2014 13:49:55 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 083561A0450 for ; Wed, 5 Mar 2014 13:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2324; q=dns/txt; s=iport; t=1394056191; x=1395265791; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AQE7lsz4Snt9QzsHLXayRWLhr5Clype/GwfDrVPwR8E=; b=bmYBIUmFCKVwoDgCOnFgzH+SmyryssRK1HqWpzuaq4g5kGjFV5BeRMs6 WR1gFKGrw4JvaY6nMMdCiB37/wKT04puKT1g+Ug1LCDM74I0F+oSXL3Lb +3f2BBgfFdG+c+WzTS2zeKq8Z3fPKxVgfwrWJIY2/nY3Cr6HjSJ+rkk9L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAPCaF1OtJXG8/2dsb2JhbABagmUhO1EGwQ2BGhZ0giUBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUBwEBBQMCBBMIARKHXgEHBc5xF44gMwUGgx6BFASZb4s0hUWDLYIq X-IronPort-AV: E=Sophos;i="4.97,595,1389744000"; d="scan'208";a="25206270" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 05 Mar 2014 21:49:51 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s25Lnp78017466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 21:49:51 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 15:49:51 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: FW: I-D Action: draft-tsou-softwire-bfd-ds-lite-06.txt Thread-Topic: I-D Action: draft-tsou-softwire-bfd-ds-lite-06.txt Thread-Index: AQKGxPbZiabKZNOK06XzVYBe+AL4yplD48OwgCAKNzA= Date: Wed, 5 Mar 2014 21:49:49 +0000 Message-ID: References: <20140213073305.2032.2387.idtracker@ietfa.amsl.com> <090501cf28b6$e75bb660$b6132320$@olddog.co.uk> In-Reply-To: <090501cf28b6$e75bb660$b6132320$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AGsnusN_crWnbh-HfrRzTsAwObk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 21:49:57 -0000 FYI, individual draft in softwire WG, involving BFD. -Nobo > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 13 February 2014 07:33 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-tsou-softwire-bfd-ds-lite-06.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : DS-Lite Failure Detection and Failover > > Authors : Tina Tsou > > Brandon Li > > Cathy Zhou > > Juergen Schoenwaelder > > Reinaldo Penno > > Mohamed Boucadair > > Filename : draft-tsou-softwire-bfd-ds-lite-06.txt > > Pages : 11 > > Date : 2014-02-12 > > > > Abstract: > > In DS-Lite, the tunnel is stateless, not associated with any state > > information, and the CGN function at the AFTR is stateful. > > Currently, there is no failure detection and failover mechanism for > > both stateless tunnel and stateful CGN function, which makes it > > difficult to manage and diagnose if there is a problem. This draft > > analyzes the applicability of some of the possible solutions. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds-lite/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-tsou-softwire-bfd-ds-lite-06 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-bfd-ds-lite-06 > > > > > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Mar 5 14:02:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8199B1A0227 for ; Wed, 5 Mar 2014 14:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccPJ6qzkLVE2 for ; Wed, 5 Mar 2014 14:02:38 -0800 (PST) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB951A0175 for ; Wed, 5 Mar 2014 14:02:37 -0800 (PST) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,595,1389762000"; d="scan'208,217";a="8428272" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 05 Mar 2014 17:02:33 -0500 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 17:02:33 -0500 From: "Snyder, Brian" To: "rtg-bfd@ietf.org" Subject: Hello, use case question about BFD Thread-Topic: Hello, use case question about BFD Thread-Index: Ac84vWmXOMLqhV2dTI2t+Ls0fEMTww== Date: Wed, 5 Mar 2014 22:02:19 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_84585478AABBBF4B9DF597FC0F84AF7342F2D1DFVAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/g4B2b07Z3EXbTFgEph7ynim-OW4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 22:02:40 -0000 --_000_84585478AABBBF4B9DF597FC0F84AF7342F2D1DFVAUSMBX03idirec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have just started researching BFD and am not sure it is a viable solution= to my networking problem. If someone would be so kind as to comment on be= low I would greatly appreciate it! I am interested in determining if one could use BFD in place of a radio awa= re routing methodology (like DLEP). My problem with DLEP is that it is not= a standard yet and is therefore hard to build anything against. I'm thinking BFD could take the place, with a few caveats. It seems to me that BFD can't operate in an event driven mode, IE: Sending = a DOWN control packet. Therefore it is very chatty, even more-so then the = L3 hello's I'm hoping to minimize. Since the main purpose is to give quick= er convergence then I am willing to configure all the L3 HELLOs (bandwidth = is expensive in my environment), I was wondering if 'proxy-ing' the BFD con= nections is a viable solution (of course assuming no authentication). IE: RTR-H ----- HUB-MDM <-> MDM-A --- RTR-A = MDM-B --- RTR-B So I'm curious if I could have HUB-MDM "proxy/spoof" the BFD control packet= s for RTR A and B and have MDM -A/B proxy for Rtr -A/b respectively. Is there any reason why this couldn't work? If any MDM dropped out of netw= ork, then HUB-MDM would simply stop proxying on his behalf, and RTR-H shoul= d figure it out and kill the peer at BFD speeds. Assuming I am on the correct track, would it be further possible to aggrega= te with the descrimitor field at HUB-MDM to only have one BFD session going= for all Modems. There could be thousands of MDM in one network and I woul= d envision this could be a scale problem for RTR-H to manage all this, as w= ell as pps scale issue processing all those for both RTR-H and HUB-MDM. Any thoughts? I am new too this and wondering if I am on the right track or= wasting my time considering BFD for this purpose.... Thanks, Brian Snyder Snr. Applied Researcher --_000_84585478AABBBF4B9DF597FC0F84AF7342F2D1DFVAUSMBX03idirec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I have just started researching BFD and am not sure = it is a viable solution to my networking problem.  If someone would be= so kind as to comment on below I would greatly appreciate it!

 

I am interested in determining if one could use BFD = in place of a radio aware routing methodology (like DLEP).  My problem= with DLEP is that it is not a standard yet and is therefore hard to build = anything against.

 

I’m thinking BFD could take the place, with a = few caveats.

 

It seems to me that BFD can’t operate in an ev= ent driven mode, IE: Sending a DOWN control packet.  Therefore it is v= ery chatty, even more-so then the L3 hello’s I’m hoping to mini= mize.  Since the main purpose is to give quicker convergence then I am willing to configure all the L3 HELLOs (bandwidth is expensive i= n my environment), I was wondering if ‘proxy-ing’ the BFD conne= ctions is a viable solution (of course assuming no authentication).

 

IE:

 

RTR-H -----    HUB-MDM  &nb= sp;            =            <-> = ; MDM-A ---  RTR-A

        &nbs= p;            &= nbsp;           &nbs= p;             =             &nb= sp;            =       MDM-B ---  RTR-B

 

So I’m curious if I could have HUB-MDM “= proxy/spoof” the BFD control packets for RTR A and B and have MDM = 211;A/B proxy for Rtr –A/b respectively.

 

Is there any reason why this couldn’t work?&nb= sp; If any MDM dropped out of network, then HUB-MDM would simply stop proxy= ing on his behalf, and RTR-H should figure it out and kill the peer at BFD = speeds.

 

Assuming I am on the correct track, would it be furt= her possible to aggregate with the descrimitor field at HUB-MDM to only hav= e one BFD session going for all Modems.  There could be thousands of M= DM in one network and I would envision this could be a scale problem for RTR-H to manage all this, as well as pps= scale issue processing all those for both RTR-H and HUB-MDM.

 

Any thoughts? I am new too this and wondering if I a= m on the right track or wasting my time considering BFD for this purpose= 230;.

 

Thanks,

Brian Snyder

Snr. Applied Researcher

 

--_000_84585478AABBBF4B9DF597FC0F84AF7342F2D1DFVAUSMBX03idirec_-- From nobody Wed Mar 5 14:57:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A8C1A0242 for ; Wed, 5 Mar 2014 14:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9jzjCPdezau for ; Wed, 5 Mar 2014 14:57:48 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7081A0221 for ; Wed, 5 Mar 2014 14:57:48 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-1b-5317abe39726 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 2C.AB.12743.3EBA7135; Wed, 5 Mar 2014 23:57:39 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 17:57:43 -0500 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Topic: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Index: AQHPKU6nR9GbDMvL1kyrqazOoH9UkZq0m7pAgB4k6lCAAHejsA== Date: Wed, 5 Mar 2014 22:57:41 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7773BF@eusaamb103.ericsson.se> References: <20140214063317.13350.93940.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D3397E8C3@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyuXSPn+7j1eLBBlvnmFjM7oi3+PxnG6PF u7PNLBZP5q1kt5j5YROzA6vHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx8tkE5oJ96hW3 N19hb2Dco9bFyMkhIWAisfb9bUYIW0ziwr31bF2MXBxCAkcYJZovTmSBcJYxSry+dpcFpIpN wEjixcYedpCEiEAPo8Sfq11MXYwcHMwCMRJH271BaoQFAiWWXOtiBrFFBIIkrs2fBlYiIuAk sWglWAmLgIrE5XOLWUFsXgFfiaXvPrFD7DrOKPFkyxKwiziBEt1/zrOD2IxA130/tYYJxGYW EJe49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStJzHl9jRniNE2J9bv0IVoVJaZ0P2SH2CsocXLm E5YJjGKzkEydhdAxC0nHLCQdCxhZVjFylBanluWmGxlsYgTGzzEJNt0djHteWh5ilOZgURLn /fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY3TQRrbveUYc1Qx2Ey2Wpl5ctEb/sKS9 zuKEpmsNt6TiPKUzpSXD59+YlzVth8ftoGn2vyJ2/PhrzcNX8/5Rx7OLaZIWbHVeGkJ2VvWh Ph/qg9Munj6/4gqLnWb/hIdaba2n4ipWnd13YfKil4lJLauvLdUUi2CP4XUQ9W2Z0m/P79Cg VMGlxFKckWioxVxUnAgAqYOq0W0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QeYvF5MhJ5GhGQboxgjBN7xNHiE Cc: "Samer Salam \(ssalam\)" , "Ali Sajassi \(sajassi\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 22:57:50 -0000 SGkgTm9ibywgZXQuIGFsLA0KSSBhbSBub3QgY29udmluY2VkIHRoYXQgdGhlcmUncyBzdHJvbmcg cmVxdWlyZW1lbnQgdG8gbW9uaXRvciwgYW5kIEknZCBzdHJlc3MgIm1vbml0b3IiLCBFQ01QIHBh dGggZnJvbSBhbiBhcmJpdHJhcnkgaGVhZC1lbmQgUEUuIEkgdGhpbmsgdGhhdCB0aGVyZSdzIHJl cXVpcmVtZW50IHRvIHRyYXZlcnNlIG9yIHZlcmlmeSBFQ01QIHBhdGhzLiBBbmQgdG8gdmVyaWZ5 L3RyYXZlcnNlIFMtQkZEIG9yIExTUCBQaW5nIG1heSBiZSB1c2VkLiBBdCB0aGUgc2FtZSB0aW1l IG1vbml0b3Jpbmcgb2YgRUNNUCBzaG91bGQgYmUgYmV0d2VlbiBlbmQtcG9pbnRzIG9mIEVDTVAg YSdsYSBMQUcgbW9uaXRvcmluZyBpbiBtaWNyby1CRkQuIEknbSBub3Qgc3VyZSBpZiB3ZSBjYW4g Y2FsbCB0aGlzICJsaW5rIGxheWVyIiBidXQgc2luY2UgRUNNUCBpcyBhbiBleGFtcGxlIG9mIENv bXBvc2l0ZSBMaW5rLCBzYXlpbmcgdGhhdCBFQ01QIHNob3VsZCBiZSBtb25pdG9yZWQgYXQgbGlu ayBsYXllciBtYXkgYmUgbm90IHRvbyBmYXIgb2ZmLg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5vYm8gQWtpeWEgKG5vYm8pDQpTZW50OiBX ZWRuZXNkYXksIE1hcmNoIDA1LCAyMDE0IDg6MDYgQU0NClRvOiBWZW5nYWRhIFByYXNhZCBHb3Zp bmRhbiAodmVuZ2dvdmkpOyBydGctYmZkQGlldGYub3JnDQpDYzogU2FtZXIgU2FsYW0gKHNzYWxh bSk7IEFsaSBTYWphc3NpIChzYWphc3NpKQ0KU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZkLTAxLnR4dA0KDQpbY2hh aXIgaGF0IG9uXQ0KDQpUaGFua3MgZm9yIGJyaW5nIHRoaXMgZHJhZnQgdG8gb3VyIGF0dGVudGlv bi4NCg0KQWxsLCBwbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIGNvbW1lbnRzLg0KDQpPbmUgcG9p bnQgb2YgdGhlIGRyYWZ0IHdoaWNoIEkgd291bGQgbGlrZSB0byBwb2ludCBvdXQgJiBzZWVrIGlu cHV0L2NvbW1lbnRzIGZyb20gQkZEZXJzIC4uLg0KDQpEcmFmdCB1c2VzIExTUCBwaW5nIHRvIGJv b3RzdHJhcCBzZXNzaW9ucyBvbiBlZ3Jlc3MsIGZvciBFVlBOIEZFQy4NCkRyYWZ0IGxlYXZlcyBy b29tIGZvciBib290c3RyYXBwaW5nL3J1bm5pbmcgQkZEIHNlc3Npb24gcGVyIEVDTVAgcGF0aCwg Zm9yIEVWUE4gRkVDLg0KDQpEbyB3ZSB3YW50IHRoZXNlIHRleHRzIHRvIHJlbWFpbiwgd2hpY2gg YWxsb3dzIEVWUE4gbGF5ZXIgdG8gbW9uaXRvciBFQ01QIHBhdGhzIG9mIE1QTFMgbGF5ZXI/DQpP ciBkbyB3ZSB3YW50IEVDTVAgbW9uaXRvciB0byBiZSBsZWZ0IGF0IE1QTFMgbGF5ZXI/DQoNCkNv bW1lbnRzPw0KDQotTm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBW ZW5nYWRhIA0KPiBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKQ0KPiBTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDE0LCAyMDE0IDY6MjUgQU0NCj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gQ2M6IFNh bWVyIFNhbGFtIChzc2FsYW0pOyBBbGkgU2FqYXNzaSAoc2FqYXNzaSkNCj4gU3ViamVjdDogRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1l dnBuLWJmZC0gMDEudHh0DQo+IA0KPiBIZWxsbyBhbGwsDQo+ICAgRllJLCB0aGUgbGF0ZXN0IHJl dmlzaW9uIG9mIHRoZSBmb2xsb3dpbmcgZHJhZnQgbWF5IGJlIG9mIGludGVyZXN0IA0KPiB0byB0 aGUgbWVtYmVycyBvZiB0aGUgQkZEIFdHIGFzIHdlbGwuDQo+IFRoYW5rcw0KPiBQcmFzYWQNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDE0LCAyMDE0IDEyOjAzIFBNDQo+IFRvOiBTYW1lciBTYWxhbSAoc3NhbGFtKTsgU2Ft ZXIgU2FsYW0gKHNzYWxhbSk7IFZlbmdhZGEgUHJhc2FkIA0KPiBHb3ZpbmRhbiAodmVuZ2dvdmkp OyBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpOyBBbGkgU2FqYXNzaSANCj4gKHNh amFzc2kpOyBBbGkgU2FqYXNzaSAoc2FqYXNzaSkNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1iZmQtIA0KPiAwMS50eHQN Cj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2 cG4tYmZkLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdh ZGEgUHJhc2FkIEdvdmluZGFuIGFuZCBwb3N0ZWQgDQo+IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQo+IA0KPiBOYW1lOgkJZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZkDQo+IFJldmlzaW9u OgkwMQ0KPiBUaXRsZToJCVByb2FjdGl2ZSBmYXVsdCBkZXRlY3Rpb24gaW4gRVZQTg0KPiBEb2N1 bWVudCBkYXRlOgkyMDE0LTAyLTE0DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ IFBhZ2VzOgkJOQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtdmdvdmluZGFuLWwydnBuLQ0KPiBldnBuLWJmZC0wMS50eHQNCj4gU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZnb3Zp bmRhbi1sMnZwbi1ldnBuLQ0KPiBiZmQvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1iZmQtMDENCj4gRGlmZjog ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXZnb3ZpbmRh bi1sMnZwbi1ldnBuLQ0KPiBiZmQtMDENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3Vt ZW50IHByb3Bvc2VzIGEgcHJvYWN0aXZlLCBpbi1iYW5kIG5ldHdvcmsgT0FNIG1lY2hhbmlzbSAN Cj4gdG8NCj4gICAgZGV0ZWN0IGNvbm5lY3Rpdml0eSBmYXVsdHMgdGhhdCBhZmZlY3QgdW5pY2Fz dCBhbmQgbXVsdGktZGVzdGluYXRpb24NCj4gICAgcGF0aHMgaW4gYW4gRVZQTiBuZXR3b3JrLiBU aGUgbXVsdGktZGVzdGluYXRpb24gcGF0aHMgYXJlIHVzZWQgYnkNCj4gICAgQnJvYWRjYXN0LCB1 bmtub3duIFVuaWNhc3QgYW5kIE11bHRpY2FzdCAoQlVNKSB0cmFmZmljLiBUaGUNCj4gICAgbWVj aGFuaXNtcyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQgdXNlIHRoZSBwcmluY2lwbGVzIG9mIHRoZSB3 aWRlbHkNCj4gICAgYWRvcHRlZCBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChC RkQpIHByb3RvY29sLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Mar 5 16:11:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847C41A0005 for ; Wed, 5 Mar 2014 16:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J71J-CfKnnx2 for ; Wed, 5 Mar 2014 16:10:57 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF391A0004 for ; Wed, 5 Mar 2014 16:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7924; q=dns/txt; s=iport; t=1394064653; x=1395274253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RsYx1po3BdMnz44IYy/favwiRZDFUtBwsLEMTnfn9Ts=; b=bZ+ti4pGuftrifk2VdwI6QTsytAy9sP7PxS2zSGAD/C7B1NHO3Cs6xg+ 5YOSf9AyoOgZOl1Nne5gswok/W8jnnu5Ua5G4cK8k/slBMNnmpjB+TR4l OEy1iEiSRURfTH2+GrNlCd+TnNx00nihqCUbOnf339aQIAtojRR+5zkPn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUGAKu8F1OtJXG8/2dsb2JhbABagmUhO1EGgwS+ChmBARZ0giUBAQEDASMRQwIFBwQCAQgRBAEBAwIGHQMCAgIwFAEICAIEAQ0FCAGHaAgBBwWuHaBYF4EpjHcWGwcGgmk1gRQEmW+QeYMtgio X-IronPort-AV: E=Sophos;i="4.97,596,1389744000"; d="scan'208";a="25250412" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 06 Mar 2014 00:10:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s260ArqH001230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 00:10:53 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 18:10:52 -0600 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Topic: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Index: AQHPKU6nR9GbDMvL1kyrqazOoH9UkZq0m7pAgB4k6lCAAHejsIAAERJQ Date: Thu, 6 Mar 2014 00:10:51 +0000 Message-ID: References: <20140214063317.13350.93940.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D3397E8C3@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B7773BF@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7773BF@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.254.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hVMhrN3nBF9UhGGqUDMtMPHEAbM Cc: "Samer Salam \(ssalam\)" , "Ali Sajassi \(sajassi\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 00:11:00 -0000 SGkgR3JlZywNCg0KVGhhbmtzIGZvciBjb21tZW50cy4NClBsZWFzZSBzZWUgaW4tbGluZS4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFp bHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXJj aCAwNSwgMjAxNCA1OjU4IFBNDQo+IFRvOiBOb2JvIEFraXlhIChub2JvKTsgVmVuZ2FkYSBQcmFz YWQgR292aW5kYW4gKHZlbmdnb3ZpKTsgcnRnLQ0KPiBiZmRAaWV0Zi5vcmcNCj4gQ2M6IFNhbWVy IFNhbGFtIChzc2FsYW0pOyBBbGkgU2FqYXNzaSAoc2FqYXNzaSkNCj4gU3ViamVjdDogUkU6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZk LQ0KPiAwMS50eHQNCj4gDQo+IEhpIE5vYm8sIGV0LiBhbCwNCj4gSSBhbSBub3QgY29udmluY2Vk IHRoYXQgdGhlcmUncyBzdHJvbmcgcmVxdWlyZW1lbnQgdG8gbW9uaXRvciwgYW5kIEknZA0KPiBz dHJlc3MgIm1vbml0b3IiLCBFQ01QIHBhdGggZnJvbSBhbiBhcmJpdHJhcnkgaGVhZC1lbmQgUEUu IEkgdGhpbmsgdGhhdA0KPiB0aGVyZSdzIHJlcXVpcmVtZW50IHRvIHRyYXZlcnNlIG9yIHZlcmlm eSBFQ01QIHBhdGhzLg0KDQpZZXMgaXQgd291bGQgYmUgZ3JlYXQgdG8gc2VlIG1vcmUgcmVxdWly ZW1lbnRzIGFyb3VuZCB0aGlzLg0KDQpGb3IgdGhpcyBkcmFmdCAoRVZQTiBCRkQpIHB1cnBvc2Us IEkgYmVsaWV2ZSB0aGUgcXVlc3Rpb24gaXMsIG9uIHdoaWNoIGxheWVyLiBJZiBNUExTIG5ldHdv cmsgaGFzIEVDTVAsIHRoZW4gdmVyaWZ5aW5nIG9mIEVDTVAgc2hvdWxkIGJlIGRvbmUgYXQgTVBM UyBuZXR3b3JrIGxheWVyLCBub3QgYXQgVlBOIGxheWVyIHRyYXZlcnNpbmcgb3ZlciBNUExTIG5l dHdvcmsuDQoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2FsYW0tbDJ2 cG4tZXZwbi1vYW0tcmVxLWZybXdrLz9pbmNsdWRlX3RleHQ9MQ0KDQpbc25pcF0NCiAgIC0gYWxs IHBhdGhzLiBGb3IgTVBMUy9JUCBuZXR3b3JrcyB3aXRoIEVDTVAsIG1vbml0b3Jpbmcgb2YgYWxs DQogICB1bmljYXN0IHBhdGhzIGJldHdlZW4gTUVQcyAob24gbm9uLWFkamFjZW50IG5vZGVzKSBt YXkgbm90IGJlDQogICBwb3NzaWJsZSwgc2luY2UgdGhlIHBlci1ob3AgRUNNUCBoYXNoaW5nIGJl aGF2aW9yIG1heSB5aWVsZA0KICAgc2l0dWF0aW9ucyB3aGVyZSBpdCBpcyBpbXBvc3NpYmxlIGZv ciBhIE1FUCB0byBwaWNrIGZsb3cgZW50cm9weQ0KICAgY2hhcmFjdGVyaXN0aWNzIHRoYXQgcmVz dWx0IGluIGV4ZXJjaXNpbmcgdGhlIGV4aGF1c3RpdmUgc2V0IG9mIEVDTVANCiAgIHBhdGhzLiBN b25pdG9yaW5nIG9mIGFsbCBFQ01QIHBhdGhzIGJldHdlZW4gTUVQcyAob24gbm9uLWFkamFjZW50 DQogICBub2RlcykgaXMgbm90IGEgcmVxdWlyZW1lbnQgZm9yIEUtVlBOIE9BTS4NCltzbmlwXQ0K DQpXaGljaCBpcyBtb3JlIHJlYXNvbiBJIHF1ZXN0aW9uIHRoZSBwcmVzZW5jZSBvZiBFQ01QIHN1 cHBvcnQgaW4gZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZkLTAxLiBNeSBvcGluaW9uIHdv dWxkIGJlLCBpdCdzIHNhZmVyIHRvIHRha2Ugb3V0IHRoZSB0ZXh0cyB0byBhbGxvdyBydW5uaW5n IEJGRCBmb3IgRVZQTiBwZXIgRUNNUCBvbiBNUExTIGxheWVyLiBJZiByZXF1aXJlZCBpbiBmdXR1 cmUsIHdyaXRlIGFuIGV4dGVuc2lvbiBkcmFmdC4gSSBiZWxpZXZlIGF1dGhvcnMgb2YgZHJhZnQt dmdvdmluZGFuLWwydnBuLWV2cG4tYmZkIHdhbnRzIHRvIGhlYXIgbW9yZSBvcGluaW9uIGZyb20g dGhpcyBsaXN0Lg0KDQo+IEFuZCB0byB2ZXJpZnkvdHJhdmVyc2UgUy1CRkQgb3IgTFNQIFBpbmcg bWF5IGJlIHVzZWQuDQoNCkFncmVlLg0KDQo+IEF0IHRoZSBzYW1lIHRpbWUNCj4gbW9uaXRvcmlu ZyBvZiBFQ01QIHNob3VsZCBiZSBiZXR3ZWVuIGVuZC1wb2ludHMgb2YgRUNNUCBhJ2xhIExBRw0K PiBtb25pdG9yaW5nIGluIG1pY3JvLUJGRC4gSSdtIG5vdCBzdXJlIGlmIHdlIGNhbiBjYWxsIHRo aXMgImxpbmsgbGF5ZXIiIGJ1dA0KPiBzaW5jZSBFQ01QIGlzIGFuIGV4YW1wbGUgb2YgQ29tcG9z aXRlIExpbmssIHNheWluZyB0aGF0IEVDTVAgc2hvdWxkIGJlDQo+IG1vbml0b3JlZCBhdCBsaW5r IGxheWVyIG1heSBiZSBub3QgdG9vIGZhciBvZmYuDQoNCkkgYWdyZWUgdGhhdCBFQ01QIGJyYW5j aCBub2RlIGlzIGluIHRoZSBiZXN0IHBvc2l0aW9uIHRvIHRha2UgYWN0aW9uLCBhbHRob3VnaCBJ IGRvIG5vdCB3YW50IHRvIGV4Y2x1ZGUgcnVubmluZyB0aGUgIm1vbml0b3IiIGZyb20gaGVhZC1l bmQgUEUgKG9yIGFueSBvdGhlciBkZXZpY2UgZm9yIHRoYXQgbWF0dGVyKSwgdW50aWwsIGFzIHlv dSBzYWlkLCB3ZSBzZWUgbW9yZSByZXF1aXJlbWVudHMgYW5kIHVzZS1jYXNlcyBhcm91bmQgdGhp cy4NCg0KLU5vYm8NCg0KPiANCj4gCVJlZ2FyZHMsDQo+IAkJR3JlZw0KPiANCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5vYm8gQWtpeWENCj4gKG5vYm8pDQo+IFNlbnQ6IFdl ZG5lc2RheSwgTWFyY2ggMDUsIDIwMTQgODowNiBBTQ0KPiBUbzogVmVuZ2FkYSBQcmFzYWQgR292 aW5kYW4gKHZlbmdnb3ZpKTsgcnRnLWJmZEBpZXRmLm9yZw0KPiBDYzogU2FtZXIgU2FsYW0gKHNz YWxhbSk7IEFsaSBTYWphc3NpIChzYWphc3NpKQ0KPiBTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1iZmQtDQo+IDAxLnR4 dA0KPiANCj4gW2NoYWlyIGhhdCBvbl0NCj4gDQo+IFRoYW5rcyBmb3IgYnJpbmcgdGhpcyBkcmFm dCB0byBvdXIgYXR0ZW50aW9uLg0KPiANCj4gQWxsLCBwbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRl IGNvbW1lbnRzLg0KPiANCj4gT25lIHBvaW50IG9mIHRoZSBkcmFmdCB3aGljaCBJIHdvdWxkIGxp a2UgdG8gcG9pbnQgb3V0ICYgc2Vlaw0KPiBpbnB1dC9jb21tZW50cyBmcm9tIEJGRGVycyAuLi4N Cj4gDQo+IERyYWZ0IHVzZXMgTFNQIHBpbmcgdG8gYm9vdHN0cmFwIHNlc3Npb25zIG9uIGVncmVz cywgZm9yIEVWUE4gRkVDLg0KPiBEcmFmdCBsZWF2ZXMgcm9vbSBmb3IgYm9vdHN0cmFwcGluZy9y dW5uaW5nIEJGRCBzZXNzaW9uIHBlciBFQ01QIHBhdGgsDQo+IGZvciBFVlBOIEZFQy4NCj4gDQo+ IERvIHdlIHdhbnQgdGhlc2UgdGV4dHMgdG8gcmVtYWluLCB3aGljaCBhbGxvd3MgRVZQTiBsYXll ciB0byBtb25pdG9yDQo+IEVDTVAgcGF0aHMgb2YgTVBMUyBsYXllcj8NCj4gT3IgZG8gd2Ugd2Fu dCBFQ01QIG1vbml0b3IgdG8gYmUgbGVmdCBhdCBNUExTIGxheWVyPw0KPiANCj4gQ29tbWVudHM/ DQo+IA0KPiAtTm9ibw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBWZW5nYWRhDQo+ID4gUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSkNCj4gPiBTZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDE0LCAyMDE0IDY6MjUgQU0NCj4gPiBUbzogcnRnLWJmZEBpZXRmLm9yZw0K PiA+IENjOiBTYW1lciBTYWxhbSAoc3NhbGFtKTsgQWxpIFNhamFzc2kgKHNhamFzc2kpDQo+ID4g U3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC12Z292 aW5kYW4tbDJ2cG4tZXZwbi1iZmQtIDAxLnR4dA0KPiA+DQo+ID4gSGVsbG8gYWxsLA0KPiA+ICAg RllJLCB0aGUgbGF0ZXN0IHJldmlzaW9uIG9mIHRoZSBmb2xsb3dpbmcgZHJhZnQgbWF5IGJlIG9m IGludGVyZXN0DQo+ID4gdG8gdGhlIG1lbWJlcnMgb2YgdGhlIEJGRCBXRyBhcyB3ZWxsLg0KPiA+ IFRoYW5rcw0KPiA+IFByYXNhZA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiA+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTQsIDIwMTQgMTI6MDMgUE0NCj4g PiBUbzogU2FtZXIgU2FsYW0gKHNzYWxhbSk7IFNhbWVyIFNhbGFtIChzc2FsYW0pOyBWZW5nYWRh IFByYXNhZA0KPiA+IEdvdmluZGFuICh2ZW5nZ292aSk7IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFu ICh2ZW5nZ292aSk7IEFsaSBTYWphc3NpDQo+ID4gKHNhamFzc2kpOyBBbGkgU2FqYXNzaSAoc2Fq YXNzaSkNCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZn b3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0NCj4gPiAwMS50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0wMS50eHQNCj4g PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdhZGEgUHJhc2FkIEdvdmlu ZGFuIGFuZCBwb3N0ZWQNCj4gPiB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gTmFt ZToJCWRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZA0KPiA+IFJldmlzaW9uOgkwMQ0KPiA+ IFRpdGxlOgkJUHJvYWN0aXZlIGZhdWx0IGRldGVjdGlvbiBpbiBFVlBODQo+ID4gRG9jdW1lbnQg ZGF0ZToJMjAxNC0wMi0xNA0KPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4g UGFnZXM6CQk5DQo+ID4gVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXZnb3ZpbmRhbi1sMnZwbi0NCj4gPiBldnBuLWJmZC0wMS50eHQNCj4g PiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dmdvdmluZGFuLWwydnBuLWV2cG4tDQo+ID4gYmZkLw0KPiA+IEh0bWxpemVkOiAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1iZmQtDQo+ IDAxDQo+ID4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLQ0KPiA+IGJmZC0wMQ0KPiA+DQo+ID4gQWJzdHJh Y3Q6DQo+ID4gICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIHByb2FjdGl2ZSwgaW4tYmFuZCBu ZXR3b3JrIE9BTSBtZWNoYW5pc20NCj4gPiB0bw0KPiA+ICAgIGRldGVjdCBjb25uZWN0aXZpdHkg ZmF1bHRzIHRoYXQgYWZmZWN0IHVuaWNhc3QgYW5kIG11bHRpLWRlc3RpbmF0aW9uDQo+ID4gICAg cGF0aHMgaW4gYW4gRVZQTiBuZXR3b3JrLiBUaGUgbXVsdGktZGVzdGluYXRpb24gcGF0aHMgYXJl IHVzZWQgYnkNCj4gPiAgICBCcm9hZGNhc3QsIHVua25vd24gVW5pY2FzdCBhbmQgTXVsdGljYXN0 IChCVU0pIHRyYWZmaWMuIFRoZQ0KPiA+ICAgIG1lY2hhbmlzbXMgcHJvcG9zZWQgaW4gdGhlIGRy YWZ0IHVzZSB0aGUgcHJpbmNpcGxlcyBvZiB0aGUgd2lkZWx5DQo+ID4gICAgYWRvcHRlZCBCaWRp cmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHByb3RvY29sLg0KPiA+DQo+ID4N Cj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+ ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Mar 5 17:42:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6E81A0056; Wed, 5 Mar 2014 17:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxkE55afZ01k; Wed, 5 Mar 2014 17:42:12 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4E1A004E; Wed, 5 Mar 2014 17:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3231; q=dns/txt; s=iport; t=1394070129; x=1395279729; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FhFbZnP8NOPAOyPRWsQqno7liR09HDnAkAqx8E5A9+0=; b=ZDAnT+4COStrR4TJbCndFDiiNFuEFzRdtf0GoWVn4i5Vvu84WSON2JJ5 HymGUAZc8Jix+Bhrz1lvJnkY1HeAEnDt5+Wp+zQz+IZ0oSASL9nwvaKUY KRj1oZS4kc5Pow+HiVNnq+RMYDzA7JFby+FnN02JODcOC5bE8BWexJXmm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAInRF1OtJV2b/2dsb2JhbABagmUhgRLBE4EZFnSCJQEBAQQnXgQCAQgRBAEBCx0HMhQJCAEBBAESCBOHXgHPGheOIDgGgx6BFAEDiROhVYMtgio X-IronPort-AV: E=Sophos;i="4.97,596,1389744000"; d="scan'208";a="25264708" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 06 Mar 2014 01:42:08 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s261g8O2011287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 01:42:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 19:42:08 -0600 From: "Nobo Akiya (nobo)" To: "Snyder, Brian" , "rtg-bfd@ietf.org" , "manet@ietf.org" Subject: RE: Hello, use case question about BFD Thread-Topic: Hello, use case question about BFD Thread-Index: Ac84vWmXOMLqhV2dTI2t+Ls0fEMTwwAEEWFw Date: Thu, 6 Mar 2014 01:42:07 +0000 Message-ID: References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.254.166] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8N0gFsB2x_F7EFNj11C-kos34gg X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 01:42:14 -0000 + MANET WG Hi Brian, I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces. If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Snyder, Bria= n > Sent: Wednesday, March 05, 2014 5:02 PM > To: rtg-bfd@ietf.org > Subject: Hello, use case question about BFD >=20 > Hello all, >=20 > I have just started researching BFD and am not sure it is a viable soluti= on to > my networking problem.=A0 If someone would be so kind as to comment on > below I would greatly appreciate it! >=20 > I am interested in determining if one could use BFD in place of a radio a= ware > routing methodology (like DLEP).=A0 My problem with DLEP is that it is no= t a > standard yet and is therefore hard to build anything against. >=20 > I'm thinking BFD could take the place, with a few caveats. >=20 > It seems to me that BFD can't operate in an event driven mode, IE: Sendin= g > a DOWN control packet.=A0 Therefore it is very chatty, even more-so then = the > L3 hello's I'm hoping to minimize.=A0 Since the main purpose is to give q= uicker > convergence then I am willing to configure all the L3 HELLOs (bandwidth i= s > expensive in my environment), I was wondering if 'proxy-ing' the BFD > connections is a viable solution (of course assuming no authentication). >=20 > IE: >=20 > RTR-H -----=A0=A0=A0 HUB-MDM=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <->=A0 MDM-A ---=A0 RTR-A > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0MDM-B --- =A0RTR-B >=20 > So I'm curious if I could have HUB-MDM "proxy/spoof" the BFD control > packets for RTR A and B and have MDM -A/B proxy for Rtr -A/b > respectively. >=20 > Is there any reason why this couldn't work?=A0 If any MDM dropped out of > network, then HUB-MDM would simply stop proxying on his behalf, and > RTR-H should figure it out and kill the peer at BFD speeds. >=20 > Assuming I am on the correct track, would it be further possible to > aggregate with the descrimitor field at HUB-MDM to only have one BFD > session going for all Modems.=A0 There could be thousands of MDM in one > network and I would envision this could be a scale problem for RTR-H to > manage all this, as well as pps scale issue processing all those for both= RTR- > H and HUB-MDM. >=20 > Any thoughts? I am new too this and wondering if I am on the right track = or > wasting my time considering BFD for this purpose.. >=20 > Thanks, > Brian Snyder > Snr. Applied Researcher From nobody Thu Mar 6 03:23:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621601A0272 for ; Thu, 6 Mar 2014 03:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-EqWMdFtN8C for ; Thu, 6 Mar 2014 03:23:05 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 840741A02C4 for ; Thu, 6 Mar 2014 03:23:00 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id y10so2939101wgg.13 for ; Thu, 06 Mar 2014 03:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=tOcxAUJQmay2lgnxYvRf4IYUkPEUONugzxaBKxJ5nV8=; b=kPtUAVp6yztopBxYedWGixfz/CIj0wcMLxmV1bxWQXyT2yjJ36KslhpXVI8H/mCcWH E6gqJ1Shzmmhhk6A9TwGA/1qY2z66XPMXYRrXFcMi/bdYBhPBZPUGyjjuix1i6RsbtUt Ps5QXMoGm5rt6+ZHiZ8nINTX0DOmHULWcVXkxyY6MnDwVrhQkvwiDQCFric/vOxfWhoY rRuT4y9wBFGeq9CaqhEgWSz8+Q9HsMnJIXlJBNg52SdMn1EjohwQWRRakDS7GyJniKpW 0PDx+bRglkFgHW7btRC61P+YOkzIc+k9I5M056+MxAOuEB5nhvoOdp9h+fspoidPhERJ NlUA== X-Received: by 10.195.13.17 with SMTP id eu17mr9307651wjd.24.1394104976211; Thu, 06 Mar 2014 03:22:56 -0800 (PST) Received: from [31.133.160.146] (dhcp-a092.meeting.ietf.org. [31.133.160.146]) by mx.google.com with ESMTPSA id ux5sm15406291wjc.6.2014.03.06.03.22.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 03:22:55 -0800 (PST) References: <20140214063317.13350.93940.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D3397E8C3@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B7773BF@eusaamb103.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <30AE1C96-75EE-4C64-A666-14D869BBA7F9@gmail.com> X-Mailer: iPhone Mail (11B651) From: Sam Aldrin Subject: Re: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Date: Thu, 6 Mar 2014 11:22:52 +0000 To: "Nobo Akiya (nobo)" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/tfAf_8cAysr5Y5j6jjjQfGBIOPs Cc: "rtg-bfd@ietf.org" , "Samer Salam \(ssalam\)" , "Ali Sajassi \(sajassi\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 11:23:07 -0000 Comments inline. Sent from my iPhone > On Mar 6, 2014, at 12:10 AM, "Nobo Akiya (nobo)" wrote: >=20 > Hi Greg, >=20 > Thanks for comments. > Please see in-line. >=20 >> -----Original Message----- >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> Sent: Wednesday, March 05, 2014 5:58 PM >> To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- >> bfd@ietf.org >> Cc: Samer Salam (ssalam); Ali Sajassi (sajassi) >> Subject: RE: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-= >> 01.txt >>=20 >> Hi Nobo, et. al, >> I am not convinced that there's strong requirement to monitor, and I'd >> stress "monitor", ECMP path from an arbitrary head-end PE. I think that >> there's requirement to traverse or verify ECMP paths. >=20 > Yes it would be great to see more requirements around this. In addition I would also like to see how these requirements feed into use ca= se/real scenario. >=20 > For this draft (EVPN BFD) purpose, I believe the question is, on which lay= er. If MPLS network has ECMP, then verifying of ECMP should be done at MPLS n= etwork layer, not at VPN layer traversing over MPLS network. >=20 > http://datatracker.ietf.org/doc/draft-salam-l2vpn-evpn-oam-req-frmwk/?incl= ude_text=3D1 >=20 > [snip] > - all paths. For MPLS/IP networks with ECMP, monitoring of all > unicast paths between MEPs (on non-adjacent nodes) may not be > possible, since the per-hop ECMP hashing behavior may yield > situations where it is impossible for a MEP to pick flow entropy > characteristics that result in exercising the exhaustive set of ECMP > paths. Monitoring of all ECMP paths between MEPs (on non-adjacent > nodes) is not a requirement for E-VPN OAM. > [snip] Being co-author of the requirements draft, I feel this is very important. Ma= intaining layering boundary when and oam is used should be carefully conside= red when designing solution. >=20 > Which is more reason I question the presence of ECMP support in draft-vgov= indan-l2vpn-evpn-bfd-01. My opinion would be, it's safer to take out the tex= ts to allow running BFD for EVPN per ECMP on MPLS layer. If required in futu= re, write an extension draft. I believe authors of draft-vgovindan-l2vpn-evp= n-bfd wants to hear more opinion from this list. I concur.=20 >=20 >> And to verify/traverse S-BFD or LSP Ping may be used. >=20 > Agree. >=20 >> At the same time >> monitoring of ECMP should be between end-points of ECMP a'la LAG >> monitoring in micro-BFD. I'm not sure if we can call this "link layer" bu= t >> since ECMP is an example of Composite Link, saying that ECMP should be >> monitored at link layer may be not too far off. >=20 > I agree that ECMP branch node is in the best position to take action, alth= ough I do not want to exclude running the "monitor" from head-end PE (or any= other device for that matter), until, as you said, we see more requirements= and use-cases around this. Before we say 'this' is a requirement, use case has to be in place or explai= ned with existing solutions in mind as solution option. Only if there are ga= ps, solution has to be proposed, IMO. Otherwise we will be putting cart befo= re the donkey. Sam >=20 > -Nobo >=20 >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya >> (nobo) >> Sent: Wednesday, March 05, 2014 8:06 AM >> To: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >> Cc: Samer Salam (ssalam); Ali Sajassi (sajassi) >> Subject: RE: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-= >> 01.txt >>=20 >> [chair hat on] >>=20 >> Thanks for bring this draft to our attention. >>=20 >> All, please review and provide comments. >>=20 >> One point of the draft which I would like to point out & seek >> input/comments from BFDers ... >>=20 >> Draft uses LSP ping to bootstrap sessions on egress, for EVPN FEC. >> Draft leaves room for bootstrapping/running BFD session per ECMP path, >> for EVPN FEC. >>=20 >> Do we want these texts to remain, which allows EVPN layer to monitor >> ECMP paths of MPLS layer? >> Or do we want ECMP monitor to be left at MPLS layer? >>=20 >> Comments? >>=20 >> -Nobo >>=20 >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada >>> Prasad Govindan (venggovi) >>> Sent: Friday, February 14, 2014 6:25 AM >>> To: rtg-bfd@ietf.org >>> Cc: Samer Salam (ssalam); Ali Sajassi (sajassi) >>> Subject: FW: New Version Notification for >>> draft-vgovindan-l2vpn-evpn-bfd- 01.txt >>>=20 >>> Hello all, >>> FYI, the latest revision of the following draft may be of interest >>> to the members of the BFD WG as well. >>> Thanks >>> Prasad >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Friday, February 14, 2014 12:03 PM >>> To: Samer Salam (ssalam); Samer Salam (ssalam); Vengada Prasad >>> Govindan (venggovi); Vengada Prasad Govindan (venggovi); Ali Sajassi >>> (sajassi); Ali Sajassi (sajassi) >>> Subject: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd- >>> 01.txt >>>=20 >>>=20 >>> A new version of I-D, draft-vgovindan-l2vpn-evpn-bfd-01.txt >>> has been successfully submitted by Vengada Prasad Govindan and posted >>> to the IETF repository. >>>=20 >>> Name: draft-vgovindan-l2vpn-evpn-bfd >>> Revision: 01 >>> Title: Proactive fault detection in EVPN >>> Document date: 2014-02-14 >>> Group: Individual Submission >>> Pages: 9 >>> URL: http://www.ietf.org/internet-drafts/draft-vgovindan-l2vp= n- >>> evpn-bfd-01.txt >>> Status: https://datatracker.ietf.org/doc/draft-vgovindan-l2vpn-e= vpn- >>> bfd/ >>> Htmlized: http://tools.ietf.org/html/draft-vgovindan-l2vpn-evpn-bf= d- >> 01 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-vgovindan-l2vpn= -evpn- >>> bfd-01 >>>=20 >>> Abstract: >>> This document proposes a proactive, in-band network OAM mechanism >>> to >>> detect connectivity faults that affect unicast and multi-destination >>> paths in an EVPN network. The multi-destination paths are used by >>> Broadcast, unknown Unicast and Multicast (BUM) traffic. The >>> mechanisms proposed in the draft use the principles of the widely >>> adopted Bidirectional Forwarding Detection (BFD) protocol. >>>=20 >>>=20 >>>=20 >>>=20 >>> 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. >>>=20 >>> The IETF Secretariat >=20 From nobody Thu Mar 6 03:27:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80061A02A7 for ; Thu, 6 Mar 2014 03:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq7Q7f6yeUvD for ; Thu, 6 Mar 2014 03:27:32 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C2E681A02A2 for ; Thu, 6 Mar 2014 03:27:31 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id p61so2818577wes.41 for ; Thu, 06 Mar 2014 03:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=4MP6hGrp/KPcovOY2tUIKy4XR19Y/v8Yxgg4Qd4IdzE=; b=H5itk/AKXPnLdMLVaitk2y0jyqV+1u933cWcAX8k0ulCpOj13oOESgyD9qDknT2JeM JYKKfNqYOps8g2/hpbLGSvtgjoOR6dpRnpu2E9UbqB8telrERKCbPTe3sSYb8H1ihNDN HsHBMi16Uf1NDeUn5Fm+WCtkK4lCndTjRv01nORnB1mauZf+alk1h2MAhH812G8QPZoq HdFI1eCttK2mH4KoLUqErc+omLeXyGFrdwBN57QzQzoALU/Ud98unr7b0zrk41u/XKUM R5s1Z76y+mcKLD+KQURY/ObUe6oii4Y3u/XO/stmoar4htHg9aU/yrZx3FsppeT/a5+S BhNA== X-Received: by 10.194.175.202 with SMTP id cc10mr9296838wjc.48.1394105247507; Thu, 06 Mar 2014 03:27:27 -0800 (PST) Received: from [31.133.160.146] (dhcp-a092.meeting.ietf.org. [31.133.160.146]) by mx.google.com with ESMTPSA id h9sm15485926wjz.16.2014.03.06.03.27.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 03:27:26 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Sam Aldrin Subject: Re: Possible addition to S-BFD use-case draft? Date: Thu, 6 Mar 2014 11:27:23 +0000 To: "Nobo Akiya (nobo)" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/shUfjNIb2B4_hMQTwO_S4SXnOMo Cc: "Sam Aldrin \(sam.aldrin@gmail.com\)" , "satoru.matsushima@g.softbank.co.jp" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 11:27:33 -0000 Hi Nobo,=20 I am presuming s-bfd can do this because label stack imposed has entropy lab= el, and head end know/discovered all possible paths correct?=20 If yes, I have few questions. Will email after ietf. If no, could u explain more? Sam Sent from my iPhone > On Mar 5, 2014, at 4:06 PM, "Nobo Akiya (nobo)" wrote: >=20 > Hi S-BFD use-case draft authors, >=20 > Document reads nicely, thank you! >=20 > I'd like to propose a possible addition to the S-BFD use-case draft. >=20 > BFD MPLS (RFC5884) states: >=20 > [snip] > If there are multiple alternate paths from an ingress LSR to an > egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > determine each of these alternate paths. A BFD session SHOULD be > established for each alternate path that is discovered. > [snip] >=20 > Above implies that a BFD session should be bootstrapped per alternate (i.e= . ECMP) path, but RFC does not have further details no how to create/maintai= n multiple BFD MPLS sessions per FEC. Questions I have are: > * How should egress de-multiplex the bootstrap request per alternate path?= > * If/when number of alternate paths changes or hash key changes: > - how should ingress delete BFD sessions on egress? > - re-bootstrapping set of sessions can be [relatively] inefficient as t= hat can consume time/resources. >=20 > Alternative is to use S-BFD for multiple alternate paths for a FEC, which e= liminates the concerns raised from above questions ... and much simpler to i= mplement and operate. >=20 > If you think this will be useful, perhaps we can add this in ... >=20 > http://tools.ietf.org/html/draft-aldrin-bfd-seamless-use-case-00#section-3= .8 >=20 > or a new sub-section can be created? >=20 > Of course action resulting from this multiple path failure detection is an= other question itself, but at least we can detect this more efficiently. >=20 > -Nobo > [as individual contributor] >=20 From nobody Thu Mar 6 05:11:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6581A00E4; Wed, 5 Mar 2014 22:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdKCksP_u95b; Wed, 5 Mar 2014 22:39:53 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5E61A00CB; Wed, 5 Mar 2014 22:39:53 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so5654202yks.5 for ; Wed, 05 Mar 2014 22:39:49 -0800 (PST) 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=vIIOa3tS/43EiTkpUTUzdG5h6IqJ5JZwEQl0LnNCHKk=; b=J9/2Mlbr/hfLrB9rPFdXLwIK7bXLZbOZttaGEEs5DiZFegPOEmNX3kD7ESrQR+hipa iefNTy1xamdqn+vlKwYvjT6dAXg2jSVnz9a4H++s5Uw+uX+PKkNfgo9a13JD28oUUR9U C+zL4t+SP5isdluZ791uKesCtB6s9TrifLefEWR4lSYJQarW3VvA4Kcb7DOJAO7gIzpp F11IytpD9SHPXTu7AaiXf9z9uCdFNxVCykX1mGrNGOcZTnvkMHlza0bKe3NAdxDwtAAs SbAGmq02OiCFWxWQ0UlgU3vDRuiJ/7vX92HSCL8xIb4HJXSWERGeJ0GYtpdguhVFTZnF YXvQ== MIME-Version: 1.0 X-Received: by 10.236.182.229 with SMTP id o65mr12205607yhm.86.1394087989721; Wed, 05 Mar 2014 22:39:49 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 22:39:49 -0800 (PST) In-Reply-To: References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> Date: Thu, 6 Mar 2014 07:39:49 +0100 Message-ID: Subject: Re: [manet] Hello, use case question about BFD From: Abdussalam Baryun To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=20cf30563ed369bdf804f3ea6792 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/cS0rg-1mSgZ1YTp1uDxCNMpJfWA X-Mailman-Approved-At: Thu, 06 Mar 2014 05:11:43 -0800 Cc: "rtg-bfd@ietf.org" , "manet@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 06:39:56 -0000 --20cf30563ed369bdf804f3ea6792 Content-Type: text/plain; charset=ISO-8859-1 Hi Nobo and Brian, You discussion is not easy for me to find your theory in IETF or in MANET. However, I never say no to reasonable discuss because it is why the list is created. Comments below, On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote: > + MANET WG > > Hi Brian, > > I agree that no existing BFD would fit well into MANET scenario. Instead > of a proxy approach, I would see variant of multipoint BFD or > broadcast-style BFD may be simpler and more fitting, where each MANET > interface would periodically broadcast BFD packets and remote state is > maintained by reception of received BFD packets from remote MANET > interfaces. Was this MANET method BFD documented/published before in or out IETF? Please give link > > If MANET WG thinks, in addition to DLEP, having an efficient hello > mechanism will be useful and at layer 3, then this would be a technically > interesting problem to discuss further. I cannot think about it only if I can understand the purpose problem and solution. I did not understand your points. > -Nobo > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org ] On > Behalf Of Snyder, Brian > > Sent: Wednesday, March 05, 2014 5:02 PM > > To: rtg-bfd@ietf.org > > Subject: Hello, use case question about BFD > > > > Hello all, > > > > I have just started researching BFD and am not sure it is a viable > solution to > > my networking problem. If someone would be so kind as to comment on > > below I would greatly appreciate it! > > > > I am interested in determining if one could use BFD in place of a radio > aware > > routing methodology (like DLEP). My problem with DLEP is that it is not > a > > standard yet and is therefore hard to build anything against. Yes not standard, but it is published, adopted technology by some companies and adopted by IETF MANET WG. Why you use BFD which still not published or used for MANET in community. It may be good but not clear yet, and you did not compare yet between performance of DLEP and BFD performance in MANET so how you decided. > > > I'm thinking BFD could take the place, with a few caveats. I don't think you convinced and your argument is weak. You replacing DLEP by BFD in a MANET scenario, why? > > > It seems to me that BFD can't operate in an event driven mode, IE: > Sending > > a DOWN control packet. Therefore it is very chatty, even more-so then > the > > L3 hello's I'm hoping to minimize. Since the main purpose is to give > quicker > > convergence then I am willing to configure all the L3 HELLOs (bandwidth > is > > expensive in my environment), I was wondering if 'proxy-ing' the BFD > > connections is a viable solution (of course assuming no authentication). How do you compare between both DLEP and BDF solutions for the problem, then we can think clear of if BDF is viable. I don't think of new solution if I have better one published. I don't know if viable only after comparing popular practice solution with new theory solution. Best regards AB --20cf30563ed369bdf804f3ea6792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nobo and Brian,

You discussion is not easy for me to = find your theory in IETF or in MANET. However, I never say no to reasonable= =A0discuss because it is why the list is created.=A0=A0Comments below,
<= br> On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote:
+ MANET WG

Hi Brian,

I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces.

Was this MANET=A0method BFD=A0documented/published befo= re in or out IETF? Please give link

If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further.

I cannot thi= nk about it only if I can understand the purpose problem=A0and solution. I = did not understand your points.=A0



-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org= ] On Behalf Of Snyder, Brian
> Sent: Wednesday, March 05, 2014 5:02 PM
> To: rtg-bfd@ietf.org
> Subject: Hello, use case question about BFD
>
> Hello all,
>
> I have just started researching BFD and am not sure it is a viable sol= ution to
> my networking problem.=A0 If someone would be so kind as to comment on=
> below I would greatly appreciate it!
>
> I am interested in determining if one could use BFD in place of a radi= o aware
> routing methodology (like DLEP).=A0 My problem with DLEP is that it is= not a
> standard yet and is therefore hard to build anything against.

Yes not standard, but it is published, adopted tech= nology by some companies and adopted by IETF MANET WG. Why you use BFD whic= h still not published or used=A0for MANET in community. It may be good but = not clear yet, and you did not compare yet between performance of=A0DLEP an= d BFD performance=A0in MANET=A0so how you decided.

>
> I'm thinking BFD could take the place, with a few caveats.

I don't think you convinced and your argument = is weak. You replacing DLEP by BFD in a MANET scenario, why?=A0

>
> It seems to me that BFD can't operate in an event driven mode, IE:= Sending
> a DOWN control packet.=A0 Therefore it is very chatty, even more-so th= en the
> L3 hello's I'm hoping to minimize.=A0 Since the main purpose i= s to give quicker
> convergence then I am willing to configure all the L3 HELLOs (bandwidt= h is
> expensive in my environment), I was wondering if 'proxy-ing' t= he BFD
> connections is a viable solution (of course assuming no authentication= ).

How do you compare between both DLEP and= BDF=A0solutions for the problem, then we can=A0think clear=A0of if BDF=A0i= s viable.=A0

=A0I don't think of new solution if I have better o= ne published. I don't know if viable only after comparing popular pract= ice=A0solution with new theory solution.=A0

Best r= egards
AB
--20cf30563ed369bdf804f3ea6792-- From nobody Thu Mar 6 05:30:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EF61A00A9 for ; Thu, 6 Mar 2014 05:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.952 X-Spam-Level: **** X-Spam-Status: No, score=4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, URIBL_SBL=20, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apVuOrv-RDNd for ; Thu, 6 Mar 2014 05:29:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D24B41A0228 for ; Thu, 6 Mar 2014 05:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3047; q=dns/txt; s=iport; t=1394112594; x=1395322194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XnO1+lmBX6Jnp0LB7Vhr3HLqJs14h6pW8/LAg2c0zrQ=; b=k/3Wsd0Lw/2iHT9DYcuFt39xGdJ1FkQwy+WZr4iVXkrFMu36d/FE1Ql5 RtGawCvZiWvSaiSXJl/kdnZ+YHZEetoLRVlqQl6+YQBhkA8RhlEPqMHHg SFWmpxV9CP3O0JRaU8cYQ1/w/Ml1DwqsrHzKupYW6SMi339uTk1jJ76Xw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFALV3GFOtJV2Z/2dsb2JhbABagmUhO1fBH4EUFnSCJQEBAQMBOj8MBAIBCBEEAQEBChQJByERFAkIAQEEDgUIh10DCQgBDMgVDYZ1F4xEgTURAR8xBwaDHoEUBJZRgx+LMYVIgy2BcTk X-IronPort-AV: E=Sophos;i="4.97,600,1389744000"; d="scan'208";a="308455852" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 06 Mar 2014 13:29:53 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s26DTrL9015571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 13:29:53 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.03.0123.003; Thu, 6 Mar 2014 07:29:53 -0600 From: "Nobo Akiya (nobo)" To: Sam Aldrin Subject: RE: Possible addition to S-BFD use-case draft? Thread-Topic: Possible addition to S-BFD use-case draft? Thread-Index: Ac84hmdERRnvRqtWQuCLjKvrLSpA0QA2u52AAAiaFdA= Date: Thu, 6 Mar 2014 13:29:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zM7b4NfGWPsVPNRgud5yqJEbtX8 Cc: "Sam Aldrin \(sam.aldrin@gmail.com\)" , "satoru.matsushima@g.softbank.co.jp" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 13:29:59 -0000 Hi Sam, Thanks for comments. Please see in-line. > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Thursday, March 06, 2014 6:27 AM > To: Nobo Akiya (nobo) > Cc: Sam Aldrin (sam.aldrin@gmail.com); Bhatia, Manav (Manav) > (manav.bhatia@alcatel-lucent.com); Gregory Mirsky > (gregory.mirsky@ericsson.com); Nagendra Kumar Nainar (naikumar); > satoru.matsushima@g.softbank.co.jp; rtg-bfd@ietf.org > Subject: Re: Possible addition to S-BFD use-case draft? >=20 > Hi Nobo, >=20 > I am presuming s-bfd can do this because label stack imposed has entropy > label, and head end know/discovered all possible paths correct? Correct. Entropy label is what I have in mind, although other entropies (ha= sh keys) are possible in certain scenarios (ex: destination IP addresses, i= f network employs 3-tuple hashing). >=20 > If yes, I have few questions. Will email after ietf. Sure. As long as you don't ask about how entropies are discovered or what a= ction should be taken if S-BFD on one of the ECMP paths fails. I know that = you know the former one very well. The latter ... if you have good ideas, e= mail me :) -Nobo >=20 > If no, could u explain more? >=20 > Sam >=20 > Sent from my iPhone >=20 > > On Mar 5, 2014, at 4:06 PM, "Nobo Akiya (nobo)" > wrote: > > > > Hi S-BFD use-case draft authors, > > > > Document reads nicely, thank you! > > > > I'd like to propose a possible addition to the S-BFD use-case draft. > > > > BFD MPLS (RFC5884) states: > > > > [snip] > > If there are multiple alternate paths from an ingress LSR to an > > egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > > determine each of these alternate paths. A BFD session SHOULD be > > established for each alternate path that is discovered. > > [snip] > > > > Above implies that a BFD session should be bootstrapped per alternate > (i.e. ECMP) path, but RFC does not have further details no how to > create/maintain multiple BFD MPLS sessions per FEC. Questions I have are: > > * How should egress de-multiplex the bootstrap request per alternate > path? > > * If/when number of alternate paths changes or hash key changes: > > - how should ingress delete BFD sessions on egress? > > - re-bootstrapping set of sessions can be [relatively] inefficient a= s that > can consume time/resources. > > > > Alternative is to use S-BFD for multiple alternate paths for a FEC, whi= ch > eliminates the concerns raised from above questions ... and much simpler > to implement and operate. > > > > If you think this will be useful, perhaps we can add this in ... > > > > http://tools.ietf.org/html/draft-aldrin-bfd-seamless-use-case-00#sectio= n- > 3.8 > > > > or a new sub-section can be created? > > > > Of course action resulting from this multiple path failure detection is > another question itself, but at least we can detect this more efficiently= . > > > > -Nobo > > [as individual contributor] > > From nobody Thu Mar 6 06:00:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0656F1A02A7; Thu, 6 Mar 2014 05:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZZomkp_CXuk; Thu, 6 Mar 2014 05:59:50 -0800 (PST) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 085EA1A0156; Thu, 6 Mar 2014 05:59:49 -0800 (PST) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,600,1389762000"; d="scan'208";a="8437165" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 06 Mar 2014 08:59:34 -0500 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 08:59:35 -0500 From: "Snyder, Brian" To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" , "manet@ietf.org" Subject: RE: Hello, use case question about BFD Thread-Topic: Hello, use case question about BFD Thread-Index: Ac84vWmXOMLqhV2dTI2t+Ls0fEMTwwAEEWFwAB0w6OA= Date: Thu, 6 Mar 2014 13:59:19 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342F2E69C@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WpGPJRGAVwThonxreHkKChWH1WY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 13:59:53 -0000 Nobo, Thank you for your advice. My problem with periodic anything really would = be the cost of bandwidth (even 1 small packet every second) would become ve= ry costly at scale. There could be thousands of modems in one network and i= nroute bandwidth is very expensive. My space is very unique compared to te= rrestrial architectures given how precious bandwidth is (in both directions= , but especially the inroute). With this goal in mind I think proxying mi= ght be better. I could still look into multipoint/broadcast BFD (I actuall= y didn't realize those existed, I was just reading the original RFC I guess= ). Maybe that could help me optimize the hub proxying on behalf of all the= se modems... but my goal still needs to be protect the satellite bandwidth = at all costs. Quesiton: Could BFD allow for an actual proxying node on someone's behalf. = Like is it possible to associate say 1000 different bgp peers/ospf neighbo= rs to the same IPADDR but with different discriminators. So the hub equipm= ent could track a MDM to Discriminator 'session'. Therefore the upstream r= outer implementation would need the ability to demultiplex that discriminat= or to different sessions - with the notion that the IP address you're conne= cting too is explicitly not the actual peer? From my intpretation of RFC58= 80 that's not possible. (But hopefully I'm wrong ;)) That being the case, is there any other way but to proxy (man-in-the-middle= attack) the BFD flow? That should be possible assuming no authentication = -- but clearly less than ideal. Regards, Brian -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Wednesday, March 05, 2014 8:42 PM To: Snyder, Brian; rtg-bfd@ietf.org; manet@ietf.org Subject: RE: Hello, use case question about BFD + MANET WG Hi Brian, I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces. If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Snyder,=20 > Brian > Sent: Wednesday, March 05, 2014 5:02 PM > To: rtg-bfd@ietf.org > Subject: Hello, use case question about BFD >=20 > Hello all, >=20 > I have just started researching BFD and am not sure it is a viable=20 > solution to my networking problem.=A0 If someone would be so kind as to=20 > comment on below I would greatly appreciate it! >=20 > I am interested in determining if one could use BFD in place of a=20 > radio aware routing methodology (like DLEP).=A0 My problem with DLEP is=20 > that it is not a standard yet and is therefore hard to build anything aga= inst. >=20 > I'm thinking BFD could take the place, with a few caveats. >=20 > It seems to me that BFD can't operate in an event driven mode, IE:=20 > Sending a DOWN control packet.=A0 Therefore it is very chatty, even=20 > more-so then the > L3 hello's I'm hoping to minimize.=A0 Since the main purpose is to give=20 > quicker convergence then I am willing to configure all the L3 HELLOs=20 > (bandwidth is expensive in my environment), I was wondering if=20 > 'proxy-ing' the BFD connections is a viable solution (of course assuming = no authentication). >=20 > IE: >=20 > RTR-H -----=A0=A0=A0 HUB-MDM=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <->=A0 MDM-A ---=A0 RTR-A > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 > MDM-B --- =A0RTR-B >=20 > So I'm curious if I could have HUB-MDM "proxy/spoof" the BFD control=20 > packets for RTR A and B and have MDM -A/B proxy for Rtr -A/b=20 > respectively. >=20 > Is there any reason why this couldn't work?=A0 If any MDM dropped out of= =20 > network, then HUB-MDM would simply stop proxying on his behalf, and=20 > RTR-H should figure it out and kill the peer at BFD speeds. >=20 > Assuming I am on the correct track, would it be further possible to=20 > aggregate with the descrimitor field at HUB-MDM to only have one BFD=20 > session going for all Modems.=A0 There could be thousands of MDM in one=20 > network and I would envision this could be a scale problem for RTR-H=20 > to manage all this, as well as pps scale issue processing all those=20 > for both RTR- H and HUB-MDM. >=20 > Any thoughts? I am new too this and wondering if I am on the right=20 > track or wasting my time considering BFD for this purpose.. >=20 > Thanks, > Brian Snyder > Snr. Applied Researcher From nobody Thu Mar 6 06:13:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0888D1A0357; Thu, 6 Mar 2014 06:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iYS9zU0UEoG; Thu, 6 Mar 2014 06:13:35 -0800 (PST) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 92C5C1A0361; Thu, 6 Mar 2014 06:13:23 -0800 (PST) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,600,1389762000"; d="scan'208,217";a="8437792" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 06 Mar 2014 09:13:19 -0500 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 09:13:19 -0500 From: "Snyder, Brian" To: Abdussalam Baryun , "Nobo Akiya (nobo)" Subject: RE: [manet] Hello, use case question about BFD Thread-Topic: [manet] Hello, use case question about BFD Thread-Index: Ac84vWmXOMLqhV2dTI2t+Ls0fEMTwwAEEWFwABjGK4AABO+3oA== Date: Thu, 6 Mar 2014 14:13:03 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342F2E6D4@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/1xASBpUYwMEEwz-2e6dQH6kVBxE Cc: "rtg-bfd@ietf.org" , "manet@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 14:13:44 -0000 --_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Baryun/Nobo, Thank you for your insight ... I appreciate the conversation..= .. My comments are embedded below --- Brian From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Thursday, March 06, 2014 1:40 AM To: Nobo Akiya (nobo) Cc: Snyder, Brian; rtg-bfd@ietf.org; manet@ietf.org Subject: Re: [manet] Hello, use case question about BFD Hi Nobo and Brian, You discussion is not easy for me to find your theory in IETF or in MANET. = However, I never say no to reasonable discuss because it is why the list is= created. Comments below, On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote: + MANET WG Hi Brian, I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces. Was this MANET method BFD documented/published before in or out IETF? Pleas= e give link [BS] - Not that I know of, this idea was a product of my own brainstorming = (though others may have gone down this road and I am not aware - as I just = joined both email lists recently). If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further. I cannot think about it only if I can understand the purpose problem and so= lution. I did not understand your points. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Snyder, Brian > Sent: Wednesday, March 05, 2014 5:02 PM > To: rtg-bfd@ietf.org > Subject: Hello, use case question about BFD > > Hello all, > > I have just started researching BFD and am not sure it is a viable soluti= on to > my networking problem. If someone would be so kind as to comment on > below I would greatly appreciate it! > > I am interested in determining if one could use BFD in place of a radio a= ware > routing methodology (like DLEP). My problem with DLEP is that it is not = a > standard yet and is therefore hard to build anything against. Yes not standard, but it is published, adopted technology by some companies= and adopted by IETF MANET WG. Why you use BFD which still not published or= used for MANET in community. It may be good but not clear yet, and you did= not compare yet between performance of DLEP and BFD performance in MANET s= o how you decided. [BS] - So for a few reasons I thought BFD actually solved my particular pro= blem more elegantly. DLEP would do what I am attempting to do but I have s= ome technical and political concerns. Technically, It seems much heavier then what I require. I have no need for = all the flow control / qos stuff. I simply want to propagate link state for= much faster L3 routing convergence. So aside from all the extra complicat= ions DLEP brings to the solution, it is also more limiting. There are no e= xtensions (that I know of) for having DLEP work with BGP, which is the targ= et routing method of a lot of my customers.... Which brings me to political issues... I feel I'll have very little say or = ability to affect their decisions. If I tell them they must use OSPF for in= stance, I don't think they will agree. Furthermore my second political con= cern, is it seems like one needs a less mainstream cisco build (The 'GC' li= ne) in order to get DLEP functionality on the router. I think it will be a= s big a battle to get folks to change their builds from their already appro= ved and tested rollouts (similar to asking them to change routing protocols= ). I think both these issues will make a DLEP solution very limiting to ou= r audience. Perhaps when DLEP is standardized and therefore promoted into = mainstream routing builds, this political argument will disappear.... I wou= ld love for that to happen, but it's not there yet. However, from what I can tell BFD has none of these issues. It seems to be= in standard cisco builds, it can be used with any higher level routing pro= tocol as it's more 'interface scoped'. This I felt just maps to my problem= better.... with the caveat that it is very chatty and I need to cut that d= own. So BFD has this DEMAND mode that can shut down the chattiness and if = I can proxy it and send an ADMIN_DOWN to shut down routing peers/neighbors = on behalf of modem link state, then I have solved all my problems without n= eeding any OTA chatter - which is the only natural advantage to DLEP, in my= use case. > > I'm thinking BFD could take the place, with a few caveats. I don't think you convinced and your argument is weak. You replacing DLEP b= y BFD in a MANET scenario, why? [BS] - I think I answered this above, please let me know if it's not clear. > > It seems to me that BFD can't operate in an event driven mode, IE: Sendin= g > a DOWN control packet. Therefore it is very chatty, even more-so then th= e > L3 hello's I'm hoping to minimize. Since the main purpose is to give qui= cker > convergence then I am willing to configure all the L3 HELLOs (bandwidth i= s > expensive in my environment), I was wondering if 'proxy-ing' the BFD > connections is a viable solution (of course assuming no authentication). How do you compare between both DLEP and BDF solutions for the problem, the= n we can think clear of if BDF is viable. [BS] - Also I think explained above.... I don't think of new solution if I have better one published. I don't know= if viable only after comparing popular practice solution with new theory s= olution. [BS] - I would agree with you but in this case it seems BFD is actually mor= e mainstream then DLEP, which is a factor in my decision. Best regards AB --_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Baryun/Nobo, Thank you fo= r your insight … I appreciate the conversation…. My comments ar= e embedded below --- Brian

 <= /p>

From: Abdussal= am Baryun [mailto:abdussalambaryun@gmail.com]
Sent: Thursday, March 06, 2014 1:40 AM
To: Nobo Akiya (nobo)
Cc: Snyder, Brian; rtg-bfd@ietf.org; manet@ietf.org
Subject: Re: [manet] Hello, use case question about BFD

 

Hi Nobo and Brian,

 

You discussion is not easy for me to find your theor= y in IETF or in MANET. However, I never say no to reasonable discuss b= ecause it is why the list is created.  Comments below,

On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote:

+ MANET WG

Hi Brian,

I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception of received BFD packets from remot= e MANET interfaces.

 

Was this MANET method BFD documented/publi= shed before in or out IETF? Please give link

 <= /p>

[BS] – Not that I k= now of, this idea was a product of my own brainstorming (though others may = have gone down this road and I am not aware – as I just joined both email lists recently).

 <= /p>


If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further.

 

I cannot think about it only if I can understand the= purpose problem and solution. I did not understand your points. =

 

 


-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Snyder, Brian
> Sent: Wednesday, March 05, 2014 5:02 PM
> To: rtg-bfd@ietf.org
> Subject: Hello, use case question about BFD
>
> Hello all,
>
> I have just started researching BFD and am not sure it is a viable sol= ution to
> my networking problem.  If someone would be so kind as to comment= on
> below I would greatly appreciate it!
>
> I am interested in determining if one could use BFD in place of a radi= o aware
> routing methodology (like DLEP).  My problem with DLEP is that it= is not a
> standard yet and is therefore hard to build anything against.

 

Yes not standard, but it is published, adopted techn= ology by some companies and adopted by IETF MANET WG. Why you use BFD which= still not published or used for MANET in community. It may be good bu= t not clear yet, and you did not compare yet between performance of DLEP and BFD performance in MANET&nbs= p;so how you decided.

 

[BS] – So for a few= reasons I thought BFD actually solved my particular problem more elegantly= .  DLEP would do what I am attempting to do but I have some technical and political concerns.


Technically, It seems much heavier then what I require. I have no need for = all the flow control / qos stuff. I simply want to propagate link state for= much faster L3 routing convergence.  So aside from all the extra comp= lications DLEP brings to the solution, it is also more limiting.  There are no extensions (that I know of) f= or having DLEP work with BGP, which is the target routing method of a lot o= f my customers….

 <= /p>

Which brings me to politi= cal issues… I feel I’ll have very little say or ability to affe= ct their decisions. If I tell them they must use OSPF for instance, I don’t think they will agree.  Furthermore my second political= concern, is it seems like one needs a less mainstream cisco build (The = 216;GC’ line) in order to get DLEP functionality on the router. = I think it will be as big a battle to get folks to change their builds from their already approved and tested rollouts (similar to asking = them to change routing protocols).  I think both these issues will mak= e a DLEP solution very limiting to our audience.  Perhaps when DLEP is= standardized and therefore promoted into mainstream routing builds, this political argument will disappear…. = I would love for that to happen, but it’s not there yet.

 <= /p>

However, from what I can = tell BFD has none of these issues.  It seems to be in standard cisco b= uilds, it can be used with any higher level routing protocol as it’s more ‘interface scoped’.  This I felt just = maps to my problem better…. with the caveat that it is very chatty an= d I need to cut that down.  So BFD has this DEMAND mode that can shut = down the chattiness and if I can proxy it and send an ADMIN_DOWN to shut down routing peers/neighbors on behalf of modem link state, then I ha= ve solved all my problems without needing any OTA chatter – which is = the only natural advantage to DLEP, in my use case.

 <= /p>

 <= /p>

>
> I'm thinking BFD could take the place, with a few caveats.<= /p>

 

I don't think you convinced and your argument is wea= k. You replacing DLEP by BFD in a MANET scenario, why? 

 <= /p>

[BS] – I think I an= swered this above, please let me know if it’s not clear.

 

>
> It seems to me that BFD can't operate in an event driven mode, IE: Sen= ding
> a DOWN control packet.  Therefore it is very chatty, even more-so= then the
> L3 hello's I'm hoping to minimize.  Since the main purpose is to = give quicker
> convergence then I am willing to configure all the L3 HELLOs (bandwidt= h is
> expensive in my environment), I was wondering if 'proxy-ing' the BFD > connections is a viable solution (of course assuming no authentication= ).

 

How do you compare between both DLEP and BDF so= lutions for the problem, then we can think clear of if BDF i= s viable. 

 

[BS]  - Also I think= explained above….

 <= /p>

 I don't think of new solution if I have better= one published. I don't know if viable only after comparing popular practic= e solution with new theory solution. 

 

[BS] – I would agre= e with you but in this case it seems BFD is actually more mainstream then D= LEP, which is a factor in my decision.

 <= /p>

Best regards

AB

--_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_-- From nobody Fri Mar 7 04:39:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9898D1A01E0 for ; Fri, 7 Mar 2014 04:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXM9GOHWESpZ for ; Fri, 7 Mar 2014 04:39:29 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id B2C091A01C9 for ; Fri, 7 Mar 2014 04:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9359; q=dns/txt; s=iport; t=1394195965; x=1395405565; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=JcrYO4huTZC+jHJasuZLqfbaittDayB6//D6z9OnQS0=; b=d0dznZGVZzqw5OEPZIBio4dwp95MuaCl/RvjCUDMbHeMdc5ttffx0I3g PDDZp8IA0GejKA2I+AQkU/uuWDEiyhOIiT2eWU7LEHVTkn16uSErSnoxM 4N2RV/wF5a0pMIZ1LAhnf1gT/8/MOdS0dEc6DywWLcpQdgE2dQpVGX7Gf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAGa9GVOtJXG9/2dsb2JhbABagkJEO1e4SohcgRMWdIIlAQIEZxISAQgRAwECKCYTFAkIAQEEDgWHeQ3PWxeNeFIRB4Q4BI5xiVKBMpB5gy2CKw X-IronPort-AV: E=Sophos; i="4.97,607,1389744000"; d="scan'208,217"; a="25684454" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 07 Mar 2014 12:39:25 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s27CdPcD028811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 12:39:25 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 06:39:24 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "rtg-bfd@ietf.org" Subject: Re: Security aspects with S-BFD Thread-Topic: Security aspects with S-BFD Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+GxeiW4sA Date: Fri, 7 Mar 2014 12:39:24 +0000 Message-ID: In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF3FB9DE1C21Cmmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/M7RhHfO3-eEkGUSh9xprA5UUW_g X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2014 12:39:33 -0000 --_000_CF3FB9DE1C21Cmmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As mentioned in draft-ietf-karp-bfd-analysis-01 section 6, if we use UTC time for Sequenc= e numbers (assuming Initiator and reflector are time synchronized), then we= can mitigate the problem of DOS and Replay attacks at reflectors. Please s= hare your thoughts. Thanks Regards Mallik From: , "Manav (Manav)" > Date: Thursday 7 November 2013 10:18 PM To: "rtg-bfd@ietf.org" > Subject: Security aspects with S-BFD Hi, S-BFD describes the reflector sessions which raises interesting security co= nsiderations. Since the reflector sessions are stateless (that's one of the biggest advan= tages) it's impossible for the reflector to keep track of the sequence numb= er that its heard from its peers. This means, that the reflector is suscept= ible to both inter-session and intra-session replay attacks. We had a discu= ssion internally amongst the co-authors and had the following proposal that= we wanted to vet before the WG members. Would like to hear the WGs opinion on this. 1. The Initiator picks up a crypto sequence number depending upon the authe= ntication mode that its using (meticulous or non meticulous). It sends a pa= cket to the Reflector with this seq num. 2. The reflector maintains no session state and hence does not look at the = crypto sequence number before accepting the packet. It looks at the Key ID = (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can d= o it based on its own database where it maps the neighbor to the key iD) an= d verifies the authentication data. If everything looks good, it processes = the packet. 3. When responding the Reflector needs to compute the Authentication data. = It uses the same sequence number that it received in the S-BFD packet that = it is responding to. It knows the Key ID, and thus the SA. It computes the = authentication data and sends the S-BFD packet out. 4. The Initiator receives the response from the Reflector. It only accepts = the S-BFD packet if it either comes with the same sequence number as it had= sent or its within the window that it finds acceptable (described in detai= l in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) Benefits of this scheme. 1. Reflectors continue to remain stateless despite using security. 2. Reflectors are not susceptible to replay attacks as they always respond = to S-BFD packets irrespective of the sequence number carried. 3. An attacker cannot forge packets from the Reflector since the Initiator = will only accept S-BFD packets that come with the sequence number that it h= ad originally used when sending the S-BFD packet. Drawbacks of this scheme. 1. Reflectors are susceptible to DoS attacks since they respond to all inco= ming S-BFD packets. This gets worse when cryptography is used as the work l= oad drastically increases as security is employed. Cheers, Manav --_000_CF3FB9DE1C21Cmmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <258EBC96EACF794D86DD9EA105BB2B3A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

As mention= ed in  draft-ietf-karp-bfd-analysis-01 section 6, if we use UTC time for Sequence numbers (assuming Initiator and reflect= or are time synchronized), then we can mitigate the problem of DOS and Repl= ay attacks at reflectors. Please share your thoughts.

Thanks

Regards
Mallik

From: <Bhatia>, "Manav (= Manav)" <manav.b= hatia@alcatel-lucent.com>
Date: Thursday 7 November 2013 10:1= 8 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Security aspects with S-BF= D

Hi,

S-BFD describes the reflector sessions which raises interesting securi= ty considerations.

Since the reflector sessions are stateless (that's one of the biggest = advantages) it's impossible for the reflector to keep track of the sequence= number that its heard from its peers. This means, that the reflector is su= sceptible to both inter-session and intra-session replay attacks. We had a discussion internally amongst t= he co-authors and had the following proposal that we wanted to vet before t= he WG members.

Would like to hear the WGs opinion on this.

1. The Initiator picks up a crypto sequence number depending upon the = authentication mode that its using (meticulous or non meticulous). It sends= a packet to the Reflector with this seq num.

2. The reflector maintains no session state and hence does not look at= the crypto sequence number before accepting the packet. It looks at the Ke= y ID (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it = can do it based on its own database where it maps the neighbor to the key iD) and verifies the authentication = data. If everything looks good, it processes the packet.

3. When responding the Reflector needs to compute the Authentication d= ata. It uses the same sequence number that it received in the S-BFD packet = that it is responding to. It knows the Key ID, and thus the SA. It computes= the authentication data and sends the S-BFD packet out.

4. The Initiator receives the response from the Reflector. It only acc= epts the S-BFD packet if it either comes with the same sequence number as i= t had sent or its within the window that it finds acceptable (described in = detail in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05)

Benefits of this scheme.

1. Reflectors continue to remain stateless despite using security.

2. Reflectors are not susceptible to replay attacks as they always res= pond to S-BFD packets irrespective of the sequence number carried.

3. An attacker cannot forge packets from the Reflector since the Initi= ator will only accept S-BFD packets that come with the sequence number that= it had originally used when sending the S-BFD packet.

Drawbacks of this scheme.

1. Reflectors are susceptible to DoS attacks since they respond to all= incoming S-BFD packets. This gets worse when cryptography is used as the w= ork load drastically increases as security is employed.

Cheers, Manav



--_000_CF3FB9DE1C21Cmmudigonciscocom_-- From nobody Fri Mar 7 04:58:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1DE1A01B3 for ; Fri, 7 Mar 2014 04:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYcNCHhuV22Q for ; Fri, 7 Mar 2014 04:58:17 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 13A521A01AA for ; Fri, 7 Mar 2014 04:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2503; q=dns/txt; s=iport; t=1394197093; x=1395406693; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=8Fc1xeKfLhikMK5znFd2gg4gxSgXkiATBTTETGXRaoY=; b=RmJGVSYkZbbtIi83HSjvL20gvLg27T2aApPwhYw66N84hu3atlF/pcUs wjt6MqbBHfJE1qStifRGCZ/51+wJaXFdrghIedFZ2FKMBvAIhQrF5Zprb lQJEhTPwHI0h/XCnY964ixsnfiLVxUzdGjyb9nVNZVh84wj2bs/hSIufG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHXBGVOtJV2c/2dsb2JhbABQCoMGgRLBJoETFnSCLDpRAT4vEyUCBC6HXp83sDkXjX9jhDgEjnGJUpIrgy2CKw X-IronPort-AV: E=Sophos;i="4.97,607,1389744000"; d="scan'208";a="308532225" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 07 Mar 2014 12:58:12 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s27CwCT7028090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Mar 2014 12:58:12 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 06:58:12 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "rtg-bfd@ietf.org" Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMA Date: Fri, 7 Mar 2014 12:58:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <62D5CABA1C9B134B87383223F8F2E7F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZHvQryxVvAsgtbPNoJ5SVyMzXI4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2014 12:58:18 -0000 Hi, Loop prevention =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Description: Consider a scenario where we have two nodes and both are S-BFD capable. Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) | | Man in the Middle (MiM) Node A reserved discriminator 0x01010101 and will have a reflector session in listening mode. Similarly Node B reserved discriminator 0x02020202 for its reflector session. Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this packet reaches Node B, the reflector session on Node B will swap the discriminators and IP addresses of the received packet and reflect it back, since YourDisc of the received packet matched with reserved discriminator of Node B. The reflected packet that reached Node A will have MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the received packet matched the reserved discriminator of Node A, Node A will swap the discriminators and reflects the packet back to Node B. Since reflectors MUST set the TTL of the reflected packets to 255, the above scenario will result in an infinite loop with just one malicious packet injected from MiM. FYI: Packet fields do not carry any direction information, i.e., if this is Ping packet or reply packet. Solutions =3D=3D=3D=3D=3D=3D=3D=3D=3D The current proposals are: 1. Overload "D" bit (Demand mode bit). =20 Initiator always sets the 'D' bit and reflector clears it. This way we can identify if a received packet was a reflected packet and avoid reflecting it back. However this changes the interpretation of 'D' bit. 2. Use of State field in the BFD control packets: Initiator will always send packets with State set to "DOWN" and reflector will send back packets with state field set to "UP. Reflectors will never reflect any packets with state as "UP". However the only issue is the use of state field differently i.e. state in the S-BFD control packet from initiator does not reflect the local state which is anyway not significant at reflector. 3. Use of local discriminator as My Disc at reflector: Reflector will always fill in My Discriminator with a locally allocated discriminator value (not reserved discriminators) and will not copy it from the received packet. Please share your thoughts on the proposals. Thanks Regards Mallik From nobody Fri Mar 7 08:16:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4C01A02AE for ; Fri, 7 Mar 2014 08:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJflK9liLi6R for ; Fri, 7 Mar 2014 08:16:05 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 63A1F1A029F for ; Fri, 7 Mar 2014 08:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20870; q=dns/txt; s=iport; t=1394208960; x=1395418560; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Hem2WXR2hIxweX2ww7M8231IFfLyqbUYAKcsvkbKYig=; b=aRdBmnukcK+phLdmQFjPnoxgsykdEg3x3GNHxsbhxCUBcN8y2RkcoIz2 UR59vlkD8RMPMkCel67Fo36P1c0WhkESUksY74RGAM/a78dmSzq14kifY V5SAHMneeD1FKoVkpLRVi/Kr8Xw3AnthwZeJMIDAGETwMhZKhN3Uxte/S A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAMrvGVOtJXG//2dsb2JhbABagkIjITtXuEmIXIESFnSCJQEBAQQtOgQeAgEIEQMBAQELFgcHMhQJCAEBBAESCIdxAQzPfxeNeDINExcBgySBFASZdZB5gy2CKw X-IronPort-AV: E=Sophos; i="4.97,608,1389744000"; d="scan'208,217"; a="25724639" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 07 Mar 2014 16:15:59 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s27GFxfc018097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Mar 2014 16:15:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 10:15:59 -0600 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Security aspects with S-BFD Thread-Topic: Security aspects with S-BFD Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+GxeiW4sAABDK0AA= Date: Fri, 7 Mar 2014 16:15:58 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4FACB1@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: [161.44.212.61] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E089F97xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Xnb49g4FpovkTvlLPDoYjU04RQY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2014 16:16:08 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E089F97xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good to see this discussion continuing (thank Mallik!). I'm a bit skeptical of creating a hard dependency from BFD/S-BFD to time sy= nchronization protocol. Meaning, if we do this, malfunctions in the time sy= nchronization protocol or even time drift can take down all BFD/S-BFD sessi= ons, causing instabilities in the network. I think this is a general topic (i.e. applicable to both BFD and S-BFD) tha= t should continue to be discussed, and certainly would like to hear more fr= om BFD and KARP experts. To progress S-BFD base draft, my vote would be to go with suggestion by Man= av (below) for the time being. -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Friday, March 07, 2014 7:39 AM To: rtg-bfd@ietf.org Subject: Re: Security aspects with S-BFD Hi, As mentioned in draft-ietf-karp-bfd-analysis-01 section 6, if we use UTC time for Sequenc= e numbers (assuming Initiator and reflector are time synchronized), then we= can mitigate the problem of DOS and Replay attacks at reflectors. Please s= hare your thoughts. Thanks Regards Mallik From: , "Manav (Manav)" > Date: Thursday 7 November 2013 10:18 PM To: "rtg-bfd@ietf.org" > Subject: Security aspects with S-BFD Hi, S-BFD describes the reflector sessions which raises interesting security co= nsiderations. Since the reflector sessions are stateless (that's one of the biggest advan= tages) it's impossible for the reflector to keep track of the sequence numb= er that its heard from its peers. This means, that the reflector is suscept= ible to both inter-session and intra-session replay attacks. We had a discu= ssion internally amongst the co-authors and had the following proposal that= we wanted to vet before the WG members. Would like to hear the WGs opinion on this. 1. The Initiator picks up a crypto sequence number depending upon the authe= ntication mode that its using (meticulous or non meticulous). It sends a pa= cket to the Reflector with this seq num. 2. The reflector maintains no session state and hence does not look at the = crypto sequence number before accepting the packet. It looks at the Key ID = (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can d= o it based on its own database where it maps the neighbor to the key iD) an= d verifies the authentication data. If everything looks good, it processes = the packet. 3. When responding the Reflector needs to compute the Authentication data. = It uses the same sequence number that it received in the S-BFD packet that = it is responding to. It knows the Key ID, and thus the SA. It computes the = authentication data and sends the S-BFD packet out. 4. The Initiator receives the response from the Reflector. It only accepts = the S-BFD packet if it either comes with the same sequence number as it had= sent or its within the window that it finds acceptable (described in detai= l in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) Benefits of this scheme. 1. Reflectors continue to remain stateless despite using security. 2. Reflectors are not susceptible to replay attacks as they always respond = to S-BFD packets irrespective of the sequence number carried. 3. An attacker cannot forge packets from the Reflector since the Initiator = will only accept S-BFD packets that come with the sequence number that it h= ad originally used when sending the S-BFD packet. Drawbacks of this scheme. 1. Reflectors are susceptible to DoS attacks since they respond to all inco= ming S-BFD packets. This gets worse when cryptography is used as the work l= oad drastically increases as security is employed. Cheers, Manav --_000_CECE764681BE964CBE1DFF78F3CDD3941E089F97xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good to see this discussi= on continuing (thank Mallik!).

 <= /p>

I’m a bit skeptical= of creating a hard dependency from BFD/S-BFD to time synchronization proto= col. Meaning, if we do this, malfunctions in the time synchronization protocol or even time drift can take down all BFD/S-BFD sessions, causing = instabilities in the network.

 <= /p>

I think this is a general= topic (i.e. applicable to both BFD and S-BFD) that should continue to be d= iscussed, and certainly would like to hear more from BFD and KARP experts.

 <= /p>

To progress S-BFD base dr= aft, my vote would be to go with suggestion by Manav (below) for the time b= eing.

 <= /p>

-Nobo

 <= /p>

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Friday, March 07, 2014 7:39 AM
To: rtg-bfd@ietf.org
Subject: Re: Security aspects with S-BFD

 

Hi,

 

As mentioned in  = draft-ietf-karp-bfd-analysis-01 section 6, if we use UTC time for Sequence numbers (assuming Initiator and reflect= or are time synchronized), then we can mitigate the problem of DOS and Repl= ay attacks at reflectors. Please share your thoughts.

 

Thanks

 

Regards

Mallik

 

From: <Bhatia>, "Manav (Manav)&quo= t; <manav.bhatia@alca= tel-lucent.com>
Date: Thursday 7 November 2013 10:18 PM
To: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: Security aspects with S-BFD

 

Hi,

 

S-BFD describes the reflector= sessions which raises interesting security considerations.

 

Since the reflector sessions = are stateless (that's one of the biggest advantages) it's impossible for th= e reflector to keep track of the sequence number that its heard from its peers. This means, that the reflector is susceptible to bot= h inter-session and intra-session replay attacks. We had a discussion inter= nally amongst the co-authors and had the following proposal that we wanted = to vet before the WG members.

 

Would like to hear the WGs op= inion on this.

 

1. The Initiator picks up a c= rypto sequence number depending upon the authentication mode that its using= (meticulous or non meticulous). It sends a packet to the Reflector with this seq num.

 

2. The reflector maintains no= session state and hence does not look at the crypto sequence number before= accepting the packet. It looks at the Key ID (draft-ietf-bfd-generic-crypt= o-auth-05) in the incoming packet (or it can do it based on its own database where it= maps the neighbor to the key iD) and verifies the authentication data. If = everything looks good, it processes the packet.

 

3. When responding the Reflec= tor needs to compute the Authentication data. It uses the same sequence num= ber that it received in the S-BFD packet that it is responding to. It knows the Key ID, and thus the SA. It computes the authentication d= ata and sends the S-BFD packet out.

 

4. The Initiator receives the= response from the Reflector. It only accepts the S-BFD packet if it either= comes with the same sequence number as it had sent or its within the window that it finds acceptable (described in detail in Sec 3.4= of draft-ietf-bfd-generic-crypto-auth-05)

 

Benefits of this scheme.=

 

1. Reflectors continue to rem= ain stateless despite using security.

 

2. Reflectors are not suscept= ible to replay attacks as they always respond to S-BFD packets irrespective= of the sequence number carried.

 

3. An attacker cannot forge p= ackets from the Reflector since the Initiator will only accept S-BFD packet= s that come with the sequence number that it had originally used when sending the S-BFD packet.

 

Drawbacks of this scheme.

 

1. Reflectors are susceptible= to DoS attacks since they respond to all incoming S-BFD packets. This gets= worse when cryptography is used as the work load drastically increases as security is employed.

 

Cheers, Manav

 

 

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941E089F97xmbalnx01ciscoc_-- From nobody Sat Mar 8 10:46:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048601A00AA for ; Sat, 8 Mar 2014 10:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbdTSSWCO4Uc for ; Sat, 8 Mar 2014 10:46:23 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id EF8831A0030 for ; Sat, 8 Mar 2014 10:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3746; q=dns/txt; s=iport; t=1394304378; x=1395513978; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1SjM9qOUEoortY4FcJAMKXBO9bX9Ost6oDE/Z/snl4s=; b=kYLK07re90TJdnThfidq/+a6v0Yb42ts9KhMW2rTYOTgE2L3VwW3tSkN xKoWGit32hF6LktBRh1LNQ5qegxPdu5sJ1ZxvTFeD3Q1CspfN1PdjX6eZ WnbW+YMJzpHVvlnPeGVkvvl0PhpRL9KBa4Se/ebS/UTw2ZMZ3ltONn5yN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPxkG1OtJV2d/2dsb2JhbABQCoJlIYESwTKBCxZ0giUBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEggTh14Bz3YXjX8rOAaDHoEUAQOqcoMtgWkGPA X-IronPort-AV: E=Sophos;i="4.97,615,1389744000"; d="scan'208";a="25928411" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 08 Mar 2014 18:46:18 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s28IkImP020348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 8 Mar 2014 18:46:18 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.03.0123.003; Sat, 8 Mar 2014 12:46:17 -0600 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpA= Date: Sat, 8 Mar 2014 18:46:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/HDDWnrsaDOyDOYXa1D8NHIk0h7M X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Mar 2014 18:46:25 -0000 Hi Mallik, et al, My preference: 1 > 2 > 3 Reasons: [3] Deviating discriminator by reflector session - Proposed will prevent a = single S-BFD session to speak to multiple reflectors (cannot do reply demux= 'ing), if implementation wants to do this or if there is ever such use-case= . [2] State - No strong opposition here, but just looks cleaner for S-BFD ini= tiator to reflect session state in state field of packets sent. =20 [1] D bit - I can't think of any reason why S-BFD initiator wants to set D = bit in packet to reflector session that is stateless. If S-BFD initiator is= not interested in receiving back any response, S-BFD initiator can simply = "not send". Thus, there is no issue with changing the meaning of D bit in S= -BFD context. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > MUDIGONDA (mmudigon) > Sent: Friday, March 07, 2014 7:58 AM > To: rtg-bfd@ietf.org > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 >=20 > Hi, >=20 > Loop prevention > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Description: >=20 > Consider a scenario where we have two nodes and both are S-BFD capable. >=20 >=20 > Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > | > | > Man in the Middle (MiM) >=20 > Node A reserved discriminator 0x01010101 and will have a reflector sessio= n > in listening mode. Similarly Node B reserved discriminator 0x02020202 for > its reflector session. >=20 > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this pa= cket > reaches Node B, the reflector session on Node B will swap the > discriminators and IP addresses of the received packet and reflect it bac= k, > since YourDisc of the received packet matched with reserved discriminator > of Node B. The reflected packet that reached Node A will have > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the > received packet matched the reserved discriminator of Node A, Node A will > swap the discriminators and reflects the packet back to Node B. Since > reflectors MUST set the TTL of the reflected packets to 255, the above > scenario will result in an infinite loop with just one malicious packet > injected from MiM. >=20 > FYI: Packet fields do not carry any direction information, i.e., if this = is Ping > packet or reply packet. >=20 > Solutions > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The current proposals are: >=20 > 1. Overload "D" bit (Demand mode bit). >=20 > Initiator always sets the 'D' bit and reflector clears it. This > way we can identify if a received packet was a reflected packet > and avoid reflecting it back. However this changes the > interpretation of 'D' bit. >=20 > 2. Use of State field in the BFD control packets: >=20 > Initiator will always send packets with State set to "DOWN" > and reflector will send back packets with state field set to "UP. > Reflectors will never reflect any packets with state as "UP". > However the only issue is the use of state field differently i.e. > state in the S-BFD control packet from initiator does not > reflect the local state which is anyway not significant at reflector. >=20 > 3. Use of local discriminator as My Disc at reflector: >=20 > Reflector will always fill in My Discriminator with a locally > allocated discriminator value (not reserved discriminators) and will > not copy it from the received packet. >=20 > Please share your thoughts on the proposals. >=20 > Thanks >=20 > Regards > Mallik >=20 >=20 From nobody Sat Mar 8 13:43:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D751A02DB for ; Sat, 8 Mar 2014 13:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwIlazPmy-Ci for ; Sat, 8 Mar 2014 13:43:00 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 675311A0274 for ; Sat, 8 Mar 2014 13:42:59 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-99-531b8c8ab2d3 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 88.2B.12743.A8C8B135; Sat, 8 Mar 2014 22:32:58 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Sat, 8 Mar 2014 16:42:51 -0500 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sA== Date: Sat, 8 Mar 2014 21:42:50 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXRPrG5Xj3SwwZ2LkhZHXh1jtpjdEW/x +c82Rgdmjym/N7J6LFnykymAKYrLJiU1J7MstUjfLoEro2ffR5aCncoV65YtYWlgnCPTxcjJ ISFgIrHww1c2CFtM4sK99UA2F4eQwBFGie9X5rNCOMsYJR7fXQNWxSZgJPFiYw87SEJEoJVR 4t2b0ywgCWEBV4n3T+cygtgiAm4S9x6BdIPYThJ9jTOZQGwWARWJ55Ongdm8Ar4Sb552s0Bs mMEocXHBarBmTqDEy70HwYYyAt30/dQasAZmAXGJW0/mM0HcKiCxZM95ZghbVOLl43+sELaS xJzX15gh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaO0 OLUsN93IYBMjMDaOSbDp7mDc89LyEKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhhjVu17mm1s/mCX4unHm05cfVImwpvYYHawem0xt+162xm2sXFnSha1n4zi/nRa3GdP l86C5FN/fxkf2x2TKbzYan9XzlbbGd6fS0tmTLph1Jizi7F0p0v3zVo/yY+buwW5LZbenH9g 1+3jyUKf80pd62M3z8nZeHwj3zvr6EJjTovMxVavlFWVWIozEg21mIuKEwH0xA+SWwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nO47rlBHfqLwI5e_5iNtEefUzjU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Mar 2014 21:43:03 -0000 Dear Mallik, et. al, apologies for being terribly behind on processing mail queue. I was to propose use of another well-known UDP port for S-BFD but then I lo= oked closer at RFC 5881. I think that we may use UDP source port of S-BFD p= acket received by a reflector as UDP destination port in reflected packet = to break the spoofed loop. If not that, then Option #1 but with new version= (I think we'll need new version # anyway). Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Saturday, March 08, 2014 10:46 AM To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Mallik, et al, My preference: 1 > 2 > 3 Reasons: [3] Deviating discriminator by reflector session - Proposed will prevent a = single S-BFD session to speak to multiple reflectors (cannot do reply demux= 'ing), if implementation wants to do this or if there is ever such use-case= . [2] State - No strong opposition here, but just looks cleaner for S-BFD ini= tiator to reflect session state in state field of packets sent. =20 [1] D bit - I can't think of any reason why S-BFD initiator wants to set D = bit in packet to reflector session that is stateless. If S-BFD initiator is= not interested in receiving back any response, S-BFD initiator can simply = "not send". Thus, there is no issue with changing the meaning of D bit in S= -BFD context. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK=20 > MUDIGONDA (mmudigon) > Sent: Friday, March 07, 2014 7:58 AM > To: rtg-bfd@ietf.org > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 >=20 > Hi, >=20 > Loop prevention > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Description: >=20 > Consider a scenario where we have two nodes and both are S-BFD capable. >=20 >=20 > Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > | > | > Man in the Middle (MiM) >=20 > Node A reserved discriminator 0x01010101 and will have a reflector=20 > session in listening mode. Similarly Node B reserved discriminator=20 > 0x02020202 for its reflector session. >=20 > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc=20 > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this=20 > packet reaches Node B, the reflector session on Node B will swap the=20 > discriminators and IP addresses of the received packet and reflect it=20 > back, since YourDisc of the received packet matched with reserved=20 > discriminator of Node B. The reflected packet that reached Node A will=20 > have > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the=20 > received packet matched the reserved discriminator of Node A, Node A=20 > will swap the discriminators and reflects the packet back to Node B.=20 > Since reflectors MUST set the TTL of the reflected packets to 255, the=20 > above scenario will result in an infinite loop with just one malicious=20 > packet injected from MiM. >=20 > FYI: Packet fields do not carry any direction information, i.e., if=20 > this is Ping packet or reply packet. >=20 > Solutions > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The current proposals are: >=20 > 1. Overload "D" bit (Demand mode bit). >=20 > Initiator always sets the 'D' bit and reflector clears it. This way=20 > we can identify if a received packet was a reflected packet > and avoid reflecting it back. However this changes the=20 > interpretation of 'D' bit. >=20 > 2. Use of State field in the BFD control packets: >=20 > Initiator will always send packets with State set to "DOWN" > and reflector will send back packets with state field set to "UP. > Reflectors will never reflect any packets with state as "UP". > However the only issue is the use of state field differently i.e. > state in the S-BFD control packet from initiator does not=20 > reflect the local state which is anyway not significant at reflector. >=20 > 3. Use of local discriminator as My Disc at reflector: >=20 > Reflector will always fill in My Discriminator with a locally=20 > allocated discriminator value (not reserved discriminators) and will > not copy it from the received packet. >=20 > Please share your thoughts on the proposals. >=20 > Thanks >=20 > Regards > Mallik >=20 >=20 From nobody Sun Mar 9 06:32:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6014D1A031D for ; Sun, 9 Mar 2014 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmDaNTrPT-7R for ; Sun, 9 Mar 2014 06:32:40 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A225B1A022D for ; Sun, 9 Mar 2014 06:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6023; q=dns/txt; s=iport; t=1394371956; x=1395581556; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OiNYnPeS4hktaui3KfC1KYAyw3lO9f/wjTekCsuxrrA=; b=l9+dwB+1KeKcw8U973WwESm2sF9WwX46Dys++DcNUEJNrhA3OR8bxevG 3cFZFpRvxVUNImnxHr6kamVmljY6bx3rMzkMxBDJJRc8u6Fc3227FErL7 +O34CfPey+X74QQRpjH+HBhQbd+BBqqe6pbBWm43znlS0cKRqvT+gFZkL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFANVsHFOtJXG+/2dsb2JhbABQCoJlIYESwTWBChZ0giUBAQEDATpEBwQCAQgRBAEBCxQJBzIUCQgCBAESCBOHVggBzzwXjX8LAQEeOAaDHoEUBKpygy2BaQYBAhci X-IronPort-AV: E=Sophos;i="4.97,618,1389744000"; d="scan'208";a="26033358" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-2.cisco.com with ESMTP; 09 Mar 2014 13:32:35 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s29DWZFg028187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Mar 2014 13:32:35 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sun, 9 Mar 2014 08:32:34 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQ Date: Sun, 9 Mar 2014 13:32:33 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dkgDKmcHVzEfBdBIsq5ZpLU1MWk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2014 13:32:43 -0000 Hi Mallik, Greg, [S-]BFDers, Please see in-line. > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Saturday, March 08, 2014 4:43 PM > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Dear Mallik, et. al, > apologies for being terribly behind on processing mail queue. > I was to propose use of another well-known UDP port for S-BFD but then I > looked closer at RFC 5881. S-BFD proposes to use a new well-known UDP port (starting from base-02 ... = sorry doc is still not very clear, but we've done major facelift on -03, wh= ich is to be submitted after loop/security discussions). And since differen= t UDP ports, even if were to change meaning of some fields of BFD control h= eader (ex: D bit interpretation), I don't feel that up versioning is absolu= tely required. We could, but we could also avoid. > I think that we may use UDP source port of S- > BFD packet received by a reflector as UDP destination port in reflected > packet to break the spoofed loop. Regarding usage of source UDP port to break the loop, true that's another p= ossibility. This should definitely be listed as one of the options. It woul= d require that (dest UDP port !=3D src UDP port) ... and solution is outsid= e of BFD control header (do we ever want to do IP-less?). > If not that, then Option #1 but with new > version (I think we'll need new version # anyway). I'm glad to see that you also prefer option #1. I recommend we move forward= with this, but list all other options in the appendix and keep the discuss= ion open for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, w= hat do you think? -Nobo >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Saturday, March 08, 2014 10:46 AM > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Mallik, et al, >=20 > My preference: >=20 > 1 > 2 > 3 >=20 > Reasons: >=20 > [3] Deviating discriminator by reflector session - Proposed will prevent = a > single S-BFD session to speak to multiple reflectors (cannot do reply > demux'ing), if implementation wants to do this or if there is ever such u= se- > case. >=20 > [2] State - No strong opposition here, but just looks cleaner for S-BFD > initiator to reflect session state in state field of packets sent. >=20 > [1] D bit - I can't think of any reason why S-BFD initiator wants to set = D bit > in packet to reflector session that is stateless. If S-BFD initiator is n= ot > interested in receiving back any response, S-BFD initiator can simply "no= t > send". Thus, there is no issue with changing the meaning of D bit in S-BF= D > context. >=20 > -Nobo >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > > MUDIGONDA (mmudigon) > > Sent: Friday, March 07, 2014 7:58 AM > > To: rtg-bfd@ietf.org > > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > > > Hi, > > > > Loop prevention > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Description: > > > > Consider a scenario where we have two nodes and both are S-BFD capable. > > > > > > Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > > | > > | > > Man in the Middle (MiM) > > > > Node A reserved discriminator 0x01010101 and will have a reflector > > session in listening mode. Similarly Node B reserved discriminator > > 0x02020202 for its reflector session. > > > > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, > YourDisc > > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this > > packet reaches Node B, the reflector session on Node B will swap the > > discriminators and IP addresses of the received packet and reflect it > > back, since YourDisc of the received packet matched with reserved > > discriminator of Node B. The reflected packet that reached Node A will > > have > > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the > > received packet matched the reserved discriminator of Node A, Node A > > will swap the discriminators and reflects the packet back to Node B. > > Since reflectors MUST set the TTL of the reflected packets to 255, the > > above scenario will result in an infinite loop with just one malicious > > packet injected from MiM. > > > > FYI: Packet fields do not carry any direction information, i.e., if > > this is Ping packet or reply packet. > > > > Solutions > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > The current proposals are: > > > > 1. Overload "D" bit (Demand mode bit). > > > > Initiator always sets the 'D' bit and reflector clears it. This > way > > we can identify if a received packet was a reflected packet > > and avoid reflecting it back. However this changes the > > interpretation of 'D' bit. > > > > 2. Use of State field in the BFD control packets: > > > > Initiator will always send packets with State set to "DOWN" > > and reflector will send back packets with state field set to "UP. > > Reflectors will never reflect any packets with state as "UP". > > However the only issue is the use of state field differently i.e. > > state in the S-BFD control packet from initiator does not > > reflect the local state which is anyway not significant at reflector. > > > > 3. Use of local discriminator as My Disc at reflector: > > > > Reflector will always fill in My Discriminator with a locally > > allocated discriminator value (not reserved discriminators) and will > > not copy it from the received packet. > > > > Please share your thoughts on the proposals. > > > > Thanks > > > > Regards > > Mallik > > > > From nobody Sun Mar 9 08:48:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9D01A02A4 for ; Sun, 9 Mar 2014 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXUIyT_sPRdu for ; Sun, 9 Mar 2014 08:48:06 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 973A51A0268 for ; Sun, 9 Mar 2014 08:48:06 -0700 (PDT) Received: from mail22-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.22; Sun, 9 Mar 2014 15:48:01 +0000 Received: from mail22-va3 (localhost [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id 1C3531400F3; Sun, 9 Mar 2014 15:48:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz9371I1b0bI542I1432I1418I13e6K168aJdb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h9a9j1155h) Received-SPF: pass (mail22-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=santoshpk@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(69234005)(57704003)(51444003)(377454003)(13464003)(189002)(199002)(50944004)(51704005)(74706001)(74876001)(69226001)(80976001)(81686001)(83322001)(19580405001)(19580395003)(74366001)(63696002)(65816001)(79102001)(66066001)(81342001)(81542001)(81816001)(95666003)(80022001)(49866001)(47976001)(94946001)(4396001)(33646001)(59766001)(47736001)(86362001)(50986001)(77982001)(92566001)(85306002)(87266001)(93136001)(94316002)(31966008)(95416001)(2656002)(74662001)(93516002)(47446002)(74502001)(90146001)(76482001)(51856001)(54356001)(53806001)(87936001)(97336001)(74316001)(85852003)(83072002)(46102001)(561944002)(76576001)(56816005)(76786001)(76796001)(54316002)(56776001)(97186001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB771; H:BLUPR05MB755.namprd05.prod.outlook.com; CLIP:116.197.184.15; FPR:ECD7F23F.98E29DC8.41D171A7.49F5FAF1.20596; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1394380079431355_26743; Sun, 9 Mar 2014 15:47:59 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.248]) by mail22-va3.bigfish.com (Postfix) with ESMTP id 59BC84C0070; Sun, 9 Mar 2014 15:47:59 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 9 Mar 2014 15:47:58 +0000 Received: from BLUPR05MB771.namprd05.prod.outlook.com (10.141.209.26) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Sun, 9 Mar 2014 15:47:58 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB771.namprd05.prod.outlook.com (10.141.209.26) with Microsoft SMTP Server (TLS) id 15.0.893.10; Sun, 9 Mar 2014 15:47:57 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.0888.003; Sun, 9 Mar 2014 15:47:57 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , Gregory Mirsky , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoA= Date: Sun, 9 Mar 2014 15:47:56 +0000 Message-ID: <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.15] x-forefront-prvs: 0145758B1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/w96ATbXzF83AcE50E3FM2pi1T9A X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2014 15:48:10 -0000 I prefer D-bit option too. Simply because it is clean. D-bit loses its mean= ing in S-BFD context and I don't think it will be used. Only question is do= we need to come up with a new version to use D-bit?=20 Thanks Santosh P K =20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Sunday, March 09, 2014 7:03 PM > To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Mallik, Greg, [S-]BFDers, >=20 > Please see in-line. >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Saturday, March 08, 2014 4:43 PM > > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Dear Mallik, et. al, > > apologies for being terribly behind on processing mail queue. > > I was to propose use of another well-known UDP port for S-BFD but then > > I looked closer at RFC 5881. >=20 > S-BFD proposes to use a new well-known UDP port (starting from base-02 ..= . > sorry doc is still not very clear, but we've done major facelift on -03, = which is to > be submitted after loop/security discussions). And since different UDP po= rts, > even if were to change meaning of some fields of BFD control header (ex: = D bit > interpretation), I don't feel that up versioning is absolutely required. = We could, > but we could also avoid. >=20 > > I think that we may use UDP source port of S- BFD packet received by a > > reflector as UDP destination port in reflected packet to break the > > spoofed loop. >=20 > Regarding usage of source UDP port to break the loop, true that's another > possibility. This should definitely be listed as one of the options. It w= ould require > that (dest UDP port !=3D src UDP port) ... and solution is outside of BFD= control > header (do we ever want to do IP-less?). >=20 > > If not that, then Option #1 but with new version (I think we'll need > > new version # anyway). >=20 > I'm glad to see that you also prefer option #1. I recommend we move forwa= rd > with this, but list all other options in the appendix and keep the discus= sion open > for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, what do = you > think? >=20 > -Nobo >=20 > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Saturday, March 08, 2014 10:46 AM > > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Hi Mallik, et al, > > > > My preference: > > > > 1 > 2 > 3 > > > > Reasons: > > > > [3] Deviating discriminator by reflector session - Proposed will > > prevent a single S-BFD session to speak to multiple reflectors (cannot > > do reply demux'ing), if implementation wants to do this or if there is > > ever such use- case. > > > > [2] State - No strong opposition here, but just looks cleaner for > > S-BFD initiator to reflect session state in state field of packets sent= . > > > > [1] D bit - I can't think of any reason why S-BFD initiator wants to > > set D bit in packet to reflector session that is stateless. If S-BFD > > initiator is not interested in receiving back any response, S-BFD > > initiator can simply "not send". Thus, there is no issue with changing > > the meaning of D bit in S-BFD context. > > > > -Nobo > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > > > MUDIGONDA (mmudigon) > > > Sent: Friday, March 07, 2014 7:58 AM > > > To: rtg-bfd@ietf.org > > > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > > > > > > Hi, > > > > > > Loop prevention > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Description: > > > > > > Consider a scenario where we have two nodes and both are S-BFD capabl= e. > > > > > > > > > Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > > > | > > > | > > > Man in the Middle (MiM) > > > > > > Node A reserved discriminator 0x01010101 and will have a reflector > > > session in listening mode. Similarly Node B reserved discriminator > > > 0x02020202 for its reflector session. > > > > > > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, > > YourDisc > > > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When thi= s > > > packet reaches Node B, the reflector session on Node B will swap the > > > discriminators and IP addresses of the received packet and reflect > > > it back, since YourDisc of the received packet matched with reserved > > > discriminator of Node B. The reflected packet that reached Node A > > > will have > > > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the > > > received packet matched the reserved discriminator of Node A, Node A > > > will swap the discriminators and reflects the packet back to Node B. > > > Since reflectors MUST set the TTL of the reflected packets to 255, > > > the above scenario will result in an infinite loop with just one > > > malicious packet injected from MiM. > > > > > > FYI: Packet fields do not carry any direction information, i.e., if > > > this is Ping packet or reply packet. > > > > > > Solutions > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > The current proposals are: > > > > > > 1. Overload "D" bit (Demand mode bit). > > > > > > Initiator always sets the 'D' bit and reflector clears it. This > > way > > > we can identify if a received packet was a reflected packet > > > and avoid reflecting it back. However this changes the > > > interpretation of 'D' bit. > > > > > > 2. Use of State field in the BFD control packets: > > > > > > Initiator will always send packets with State set to "DOWN" > > > and reflector will send back packets with state field set to "UP. > > > Reflectors will never reflect any packets with state as "UP". > > > However the only issue is the use of state field differently i.e. > > > state in the S-BFD control packet from initiator does not > > > reflect the local state which is anyway not significant at reflector. > > > > > > 3. Use of local discriminator as My Disc at reflector: > > > > > > Reflector will always fill in My Discriminator with a locally > > > allocated discriminator value (not reserved discriminators) and will > > > not copy it from the received packet. > > > > > > Please share your thoughts on the proposals. > > > > > > Thanks > > > > > > Regards > > > Mallik > > > > > > >=20 >=20 From nobody Sun Mar 9 16:32:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EBD1A0259 for ; Sun, 9 Mar 2014 16:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz-cxtrPgZVG for ; Sun, 9 Mar 2014 16:32:26 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 675991A0257 for ; Sun, 9 Mar 2014 16:32:26 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s29NWH9I005062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Mar 2014 18:32:17 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s29NWGLx025293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Mar 2014 19:32:16 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 9 Mar 2014 19:32:16 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Mon, 10 Mar 2014 07:32:14 +0800 From: "Bhatia, Manav (Manav)" To: Santosh P K , "Nobo Akiya (nobo)" , Gregory Mirsky , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YA== Date: Sun, 9 Mar 2014 23:32:13 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.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 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BzFmjO2-CrqVoZQPIptwgc9JHwE X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2014 23:32:29 -0000 Hi Santosh, Seamless BFD uses a new UDP port and that should be good enough to overload= the D bit. I don't think we should be revising the version number -- at l= east not based on what I have heard till now. Cheers, Manav > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > K > Sent: Sunday, March 09, 2014 9:18 PM > To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); > rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > I prefer D-bit option too. Simply because it is clean. D-bit loses its > meaning in S-BFD context and I don't think it will be used. Only > question is do we need to come up with a new version to use D-bit? >=20 > Thanks > Santosh P K >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > Akiya > > (nobo) > > Sent: Sunday, March 09, 2014 7:03 PM > > To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Hi Mallik, Greg, [S-]BFDers, > > > > Please see in-line. > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Saturday, March 08, 2014 4:43 PM > > > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- > bfd@ietf.org > > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > base) > > > > > > Dear Mallik, et. al, > > > apologies for being terribly behind on processing mail queue. > > > I was to propose use of another well-known UDP port for S-BFD but > then > > > I looked closer at RFC 5881. > > > > S-BFD proposes to use a new well-known UDP port (starting from base- > 02 ... > > sorry doc is still not very clear, but we've done major facelift on - > 03, which is to > > be submitted after loop/security discussions). And since different > UDP ports, > > even if were to change meaning of some fields of BFD control header > (ex: D bit > > interpretation), I don't feel that up versioning is absolutely > required. We could, > > but we could also avoid. > > > > > I think that we may use UDP source port of S- BFD packet received > by a > > > reflector as UDP destination port in reflected packet to break the > > > spoofed loop. > > > > Regarding usage of source UDP port to break the loop, true that's > another > > possibility. This should definitely be listed as one of the options. > It would require > > that (dest UDP port !=3D src UDP port) ... and solution is outside of > BFD control > > header (do we ever want to do IP-less?). > > > > > If not that, then Option #1 but with new version (I think we'll > need > > > new version # anyway). > > > > I'm glad to see that you also prefer option #1. I recommend we move > forward > > with this, but list all other options in the appendix and keep the > discussion open > > for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, what > do you > > think? > > > > -Nobo > > > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > > Akiya > > > (nobo) > > > Sent: Saturday, March 08, 2014 10:46 AM > > > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > base) > > > > > > Hi Mallik, et al, > > > > > > My preference: > > > > > > 1 > 2 > 3 > > > > > > Reasons: > > > > > > [3] Deviating discriminator by reflector session - Proposed will > > > prevent a single S-BFD session to speak to multiple reflectors > (cannot > > > do reply demux'ing), if implementation wants to do this or if there > is > > > ever such use- case. > > > > > > [2] State - No strong opposition here, but just looks cleaner for > > > S-BFD initiator to reflect session state in state field of packets > sent. > > > > > > [1] D bit - I can't think of any reason why S-BFD initiator wants > to > > > set D bit in packet to reflector session that is stateless. If S- > BFD > > > initiator is not interested in receiving back any response, S-BFD > > > initiator can simply "not send". Thus, there is no issue with > changing > > > the meaning of D bit in S-BFD context. > > > > > > -Nobo > > > > > > > -----Original Message----- > > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > MALLIK > > > > MUDIGONDA (mmudigon) > > > > Sent: Friday, March 07, 2014 7:58 AM > > > > To: rtg-bfd@ietf.org > > > > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > > > > > > > > > Hi, > > > > > > > > Loop prevention > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Description: > > > > > > > > Consider a scenario where we have two nodes and both are S-BFD > capable. > > > > > > > > > > > > Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > > > > | > > > > | > > > > Man in the Middle (MiM) > > > > > > > > Node A reserved discriminator 0x01010101 and will have a > reflector > > > > session in listening mode. Similarly Node B reserved > discriminator > > > > 0x02020202 for its reflector session. > > > > > > > > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, > > > YourDisc > > > > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When > this > > > > packet reaches Node B, the reflector session on Node B will swap > the > > > > discriminators and IP addresses of the received packet and > reflect > > > > it back, since YourDisc of the received packet matched with > reserved > > > > discriminator of Node B. The reflected packet that reached Node A > > > > will have > > > > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of t= he > > > > received packet matched the reserved discriminator of Node A, > Node A > > > > will swap the discriminators and reflects the packet back to Node > B. > > > > Since reflectors MUST set the TTL of the reflected packets to > 255, > > > > the above scenario will result in an infinite loop with just one > > > > malicious packet injected from MiM. > > > > > > > > FYI: Packet fields do not carry any direction information, i.e., > if > > > > this is Ping packet or reply packet. > > > > > > > > Solutions > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > The current proposals are: > > > > > > > > 1. Overload "D" bit (Demand mode bit). > > > > > > > > Initiator always sets the 'D' bit and reflector > clears it. This > > > way > > > > we can identify if a received packet was a reflected packet > > > > and avoid reflecting it back. However this changes > the > > > > interpretation of 'D' bit. > > > > > > > > 2. Use of State field in the BFD control packets: > > > > > > > > Initiator will always send packets with State set to > "DOWN" > > > > and reflector will send back packets with state field set to "UP. > > > > Reflectors will never reflect any packets with state > as "UP". > > > > However the only issue is the use of state field differently i.e. > > > > state in the S-BFD control packet from initiator does > not > > > > reflect the local state which is anyway not significant at > reflector. > > > > > > > > 3. Use of local discriminator as My Disc at reflector: > > > > > > > > Reflector will always fill in My Discriminator with a > locally > > > > allocated discriminator value (not reserved discriminators) and > will > > > > not copy it from the received packet. > > > > > > > > Please share your thoughts on the proposals. > > > > > > > > Thanks > > > > > > > > Regards > > > > Mallik > > > > > > > > > > > > >=20 From nobody Sun Mar 9 16:35:37 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A291A0286 for ; Sun, 9 Mar 2014 16:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoYIq0ASJr7M for ; Sun, 9 Mar 2014 16:35:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3661A0259 for ; Sun, 9 Mar 2014 16:35:30 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s29NZOcL011335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Mar 2014 18:35:24 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s29NZNoC005030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Mar 2014 19:35:24 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 9 Mar 2014 19:35:22 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Mon, 10 Mar 2014 07:35:19 +0800 From: "Bhatia, Manav (Manav)" To: "Nobo Akiya (nobo)" , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Security aspects with S-BFD Thread-Topic: Security aspects with S-BFD Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+GxeiW4sAABDK0AAAUoFLIA== Date: Sun, 9 Mar 2014 23:35:19 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5A7AC9@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20211F91F544D247976D84C5D778A4C32E4FACB1@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.16] Content-Type: multipart/alternative; boundary="_000_20211F91F544D247976D84C5D778A4C32E5A7AC9SG70YWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/o5FLeRgVfW-ejUX54GU01OzfFEc X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2014 23:35:34 -0000 --_000_20211F91F544D247976D84C5D778A4C32E5A7AC9SG70YWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Nobo here. I don't think binding BFD with a timing protocol is= a good idea. > I think this is a general topic (i.e. applicable to both BFD and S-BFD) t= hat > should continue to be discussed, and certainly would like to hear more fr= om BFD and KARP experts. And pray what is that? What would you like to hear more about? Cheers, Manav From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Friday, March 07, 2014 9:46 PM To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Security aspects with S-BFD Good to see this discussion continuing (thank Mallik!). I'm a bit skeptical of creating a hard dependency from BFD/S-BFD to time sy= nchronization protocol. Meaning, if we do this, malfunctions in the time sy= nchronization protocol or even time drift can take down all BFD/S-BFD sessi= ons, causing instabilities in the network. I think this is a general topic (i.e. applicable to both BFD and S-BFD) tha= t should continue to be discussed, and certainly would like to hear more fr= om BFD and KARP experts. To progress S-BFD base draft, my vote would be to go with suggestion by Man= av (below) for the time being. -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Friday, March 07, 2014 7:39 AM To: rtg-bfd@ietf.org Subject: Re: Security aspects with S-BFD Hi, As mentioned in draft-ietf-karp-bfd-analysis-01 section 6, if we use UTC time for Sequenc= e numbers (assuming Initiator and reflector are time synchronized), then we= can mitigate the problem of DOS and Replay attacks at reflectors. Please s= hare your thoughts. Thanks Regards Mallik From: , "Manav (Manav)" > Date: Thursday 7 November 2013 10:18 PM To: "rtg-bfd@ietf.org" > Subject: Security aspects with S-BFD Hi, S-BFD describes the reflector sessions which raises interesting security co= nsiderations. Since the reflector sessions are stateless (that's one of the biggest advan= tages) it's impossible for the reflector to keep track of the sequence numb= er that its heard from its peers. This means, that the reflector is suscept= ible to both inter-session and intra-session replay attacks. We had a discu= ssion internally amongst the co-authors and had the following proposal that= we wanted to vet before the WG members. Would like to hear the WGs opinion on this. 1. The Initiator picks up a crypto sequence number depending upon the authe= ntication mode that its using (meticulous or non meticulous). It sends a pa= cket to the Reflector with this seq num. 2. The reflector maintains no session state and hence does not look at the = crypto sequence number before accepting the packet. It looks at the Key ID = (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can d= o it based on its own database where it maps the neighbor to the key iD) an= d verifies the authentication data. If everything looks good, it processes = the packet. 3. When responding the Reflector needs to compute the Authentication data. = It uses the same sequence number that it received in the S-BFD packet that = it is responding to. It knows the Key ID, and thus the SA. It computes the = authentication data and sends the S-BFD packet out. 4. The Initiator receives the response from the Reflector. It only accepts = the S-BFD packet if it either comes with the same sequence number as it had= sent or its within the window that it finds acceptable (described in detai= l in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) Benefits of this scheme. 1. Reflectors continue to remain stateless despite using security. 2. Reflectors are not susceptible to replay attacks as they always respond = to S-BFD packets irrespective of the sequence number carried. 3. An attacker cannot forge packets from the Reflector since the Initiator = will only accept S-BFD packets that come with the sequence number that it h= ad originally used when sending the S-BFD packet. Drawbacks of this scheme. 1. Reflectors are susceptible to DoS attacks since they respond to all inco= ming S-BFD packets. This gets worse when cryptography is used as the work l= oad drastically increases as security is employed. Cheers, Manav --_000_20211F91F544D247976D84C5D778A4C32E5A7AC9SG70YWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Nobo here. I= don’t think binding BFD with a timing protocol is a good idea.<= /o:p>

 <= /p>

> I thi= nk this is a general topic (i.e. applicable to both BFD and S-BFD) that

> shoul= d continue to be discussed, and certainly would like to hear more from BFD = and KARP experts.

 = ;

And pray w= hat is that? What would you like to hear more about?

 <= /p>

Cheers, Manav<= /span>

 <= /p>

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
Sent: Friday, March 07, 2014 9:46 PM
To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
Subject: RE: Security aspects with S-BFD

 

Good to se= e this discussion continuing (thank Mallik!).

 = ;

I’m = a bit skeptical of creating a hard dependency from BFD/S-BFD to time synchr= onization protocol. Meaning, if we do this, malfunctions in the time synchronization protocol or even time drift can take down all BFD/S-B= FD sessions, causing instabilities in the network.

 = ;

I think th= is is a general topic (i.e. applicable to both BFD and S-BFD) that should c= ontinue to be discussed, and certainly would like to hear more from BFD and KARP experts.

 = ;

To progres= s S-BFD base draft, my vote would be to go with suggestion by Manav (below)= for the time being.

 = ;

-Nobo=

 = ;

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Friday, March 07, 2014 7:39 AM
To: rtg-bfd@ietf.org
Subject: Re: Security aspects with S-BFD

 

Hi,=

 

As mentioned i= n  draft-ietf-karp-bfd-anal= ysis-01 section 6, if we use UTC time for Sequence numbers (assuming Initiator and reflect= or are time synchronized), then we can mitigate the problem of DOS and Repl= ay attacks at reflectors. Please share your thoughts.

 

Thanks=

 

Regards

Mallik=

 

From: <Bhatia>, "Ma= nav (Manav)" <ma= nav.bhatia@alcatel-lucent.com>
Date: Thursday 7 November 2013 10:18 PM
To: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: Security aspects with S-BFD

 

Hi,=

 

S-BFD describe= s the reflector sessions which raises interesting security considerations.<= o:p>

 

Since the refl= ector sessions are stateless (that's one of the biggest advantages) it's im= possible for the reflector to keep track of the sequence number that its heard from its peers. This means, that the reflector is susceptib= le to both inter-session and intra-session replay attacks. We had a discuss= ion internally amongst the co-authors and had the following proposal that w= e wanted to vet before the WG members.

 

Would like to = hear the WGs opinion on this.

 

1. The Initiat= or picks up a crypto sequence number depending upon the authentication mode= that its using (meticulous or non meticulous). It sends a packet to the Reflector with this seq num.

 

2. The reflect= or maintains no session state and hence does not look at the crypto sequenc= e number before accepting the packet. It looks at the Key ID (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it c= an do it based on its own database where it maps the neighbor to the key iD= ) and verifies the authentication data. If everything looks good, it proces= ses the packet.

 

3. When respon= ding the Reflector needs to compute the Authentication data. It uses the sa= me sequence number that it received in the S-BFD packet that it is responding to. It knows the Key ID, and thus the SA. It computes the= authentication data and sends the S-BFD packet out.

 

4. The Initiat= or receives the response from the Reflector. It only accepts the S-BFD pack= et if it either comes with the same sequence number as it had sent or its within the window that it finds acceptable (described in d= etail in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05)

 

Benefits of th= is scheme.

 

1. Reflectors = continue to remain stateless despite using security.

 

2. Reflectors = are not susceptible to replay attacks as they always respond to S-BFD packe= ts irrespective of the sequence number carried.

 

3. An attacker= cannot forge packets from the Reflector since the Initiator will only acce= pt S-BFD packets that come with the sequence number that it had originally used when sending the S-BFD packet.

 

Drawbacks of t= his scheme.

 

1. Reflectors = are susceptible to DoS attacks since they respond to all incoming S-BFD pac= kets. This gets worse when cryptography is used as the work load drastically increases as security is employed.

 

Cheers, Manav<= o:p>

 

 

 

--_000_20211F91F544D247976D84C5D778A4C32E5A7AC9SG70YWXCHMBA05z_-- From nobody Sun Mar 9 23:19:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AF11A03D3 for ; Sun, 9 Mar 2014 23:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ua-YxLSiErIe for ; Sun, 9 Mar 2014 23:19:08 -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 BA31A1A03D1 for ; Sun, 9 Mar 2014 23:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25116; q=dns/txt; s=iport; t=1394432343; x=1395641943; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=nf+R1iQYIe8SeKON3Q3WeJi65MWjDvAzZAO1oUZnXDk=; b=ay9gCVZyuOSRK8zKf3x4ShT+2Xq1pMwATLc5ZC/vLOKlK+rxm3aqis/I zp9fvOquagmc03WhdwahIhdQfkeWOqQ2+/4h/g1biPhjFp1OmJy84nEd/ 56NL5bH1P41HMeXgLjLYcmpAJiynzXY7mv4weJC9NyNknWbW2//Ob0Hlm w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAO9YHVOtJXG//2dsb2JhbABQCoJERIENvRuBGBYBdIN9AQEBAwF+BwYBCBEDAQEBIQcmExQJCAIEARIbh2EIxiAXjjYLAQEkGhgCBIQwAQOOWIk+khSDK4FoBgMXIg X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208,217";a="306102512" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 10 Mar 2014 06:19:02 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2A6J1Ap012338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 06:19:02 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 01:19:01 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: "Bhatia, Manav (Manav)" , Santosh P K , "Nobo Akiya (nobo)" , Gregory Mirsky , "rtg-bfd@ietf.org" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIABIfSA Date: Mon, 10 Mar 2014 06:19:01 +0000 Message-ID: In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF43569B1C305mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/K4lrlMCEhZyIlQkvPIwSR7f__OQ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 06:19:12 -0000 --_000_CF43569B1C305mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Good that we have some consensus to use D bit as the option. We will update= the draft 03 with this and also list all other options discussed in the ap= pendix so that all are aware of these. We will include the UDP port based s= olution suggested by Greg also. Thanks Regards Mallik From: , "Manav (Manav)" > Date: Monday 10 March 2014 5:02 AM To: Santosh P K >, "Nob= o Akiya (nobo)" >, Gregory Mirsky >, Cisco Emplo= yee >, "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Santosh, Seamless BFD uses a new UDP port and that should be good enough to overload= the D bit. I don't think we should be revising the version number -- at l= east not based on what I have heard till now. Cheers, Manav -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Sunday, March 09, 2014 9:18 PM To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) I prefer D-bit option too. Simply because it is clean. D-bit loses its meaning in S-BFD context and I don't think it will be used. Only question is do we need to come up with a new version to use D-bit? Thanks Santosh P K > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Sunday, March 09, 2014 7:03 PM > To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > Hi Mallik, Greg, [S-]BFDers, > > Please see in-line. > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Saturday, March 08, 2014 4:43 PM > > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- base) > > > > Dear Mallik, et. al, > > apologies for being terribly behind on processing mail queue. > > I was to propose use of another well-known UDP port for S-BFD but then > > I looked closer at RFC 5881. > > S-BFD proposes to use a new well-known UDP port (starting from base- 02 ... > sorry doc is still not very clear, but we've done major facelift on - 03, which is to > be submitted after loop/security discussions). And since different UDP ports, > even if were to change meaning of some fields of BFD control header (ex: D bit > interpretation), I don't feel that up versioning is absolutely required. We could, > but we could also avoid. > > > I think that we may use UDP source port of S- BFD packet received by a > > reflector as UDP destination port in reflected packet to break the > > spoofed loop. > > Regarding usage of source UDP port to break the loop, true that's another > possibility. This should definitely be listed as one of the options. It would require > that (dest UDP port !=3D src UDP port) ... and solution is outside of BFD control > header (do we ever want to do IP-less?). > > > If not that, then Option #1 but with new version (I think we'll need > > new version # anyway). > > I'm glad to see that you also prefer option #1. I recommend we move forward > with this, but list all other options in the appendix and keep the discussion open > for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, what do you > think? > > -Nobo > > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Saturday, March 08, 2014 10:46 AM > > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- base) > > > > Hi Mallik, et al, > > > > My preference: > > > > 1 > 2 > 3 > > > > Reasons: > > > > [3] Deviating discriminator by reflector session - Proposed will > > prevent a single S-BFD session to speak to multiple reflectors (cannot > > do reply demux'ing), if implementation wants to do this or if there is > > ever such use- case. > > > > [2] State - No strong opposition here, but just looks cleaner for > > S-BFD initiator to reflect session state in state field of packets sent. > > > > [1] D bit - I can't think of any reason why S-BFD initiator wants to > > set D bit in packet to reflector session that is stateless. If S- BFD > > initiator is not interested in receiving back any response, S-BFD > > initiator can simply "not send". Thus, there is no issue with changing > > the meaning of D bit in S-BFD context. > > > > -Nobo > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > > > MUDIGONDA (mmudigon) > > > Sent: Friday, March 07, 2014 7:58 AM > > > To: rtg-bfd@ietf.org > > > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > > > > > > Hi, > > > > > > Loop prevention > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Description: > > > > > > Consider a scenario where we have two nodes and both are S-BFD capable. > > > > > > > > > Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > > > | > > > | > > > Man in the Middle (MiM) > > > > > > Node A reserved discriminator 0x01010101 and will have a reflector > > > session in listening mode. Similarly Node B reserved discriminator > > > 0x02020202 for its reflector session. > > > > > > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, > > YourDisc > > > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this > > > packet reaches Node B, the reflector session on Node B will swap the > > > discriminators and IP addresses of the received packet and reflect > > > it back, since YourDisc of the received packet matched with reserved > > > discriminator of Node B. The reflected packet that reached Node A > > > will have > > > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the > > > received packet matched the reserved discriminator of Node A, Node A > > > will swap the discriminators and reflects the packet back to Node B. > > > Since reflectors MUST set the TTL of the reflected packets to 255, > > > the above scenario will result in an infinite loop with just one > > > malicious packet injected from MiM. > > > > > > FYI: Packet fields do not carry any direction information, i.e., if > > > this is Ping packet or reply packet. > > > > > > Solutions > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > The current proposals are: > > > > > > 1. Overload "D" bit (Demand mode bit). > > > > > > Initiator always sets the 'D' bit and reflector clears it. This > > way > > > we can identify if a received packet was a reflected packet > > > and avoid reflecting it back. However this changes the > > > interpretation of 'D' bit. > > > > > > 2. Use of State field in the BFD control packets: > > > > > > Initiator will always send packets with State set to "DOWN" > > > and reflector will send back packets with state field set to "UP. > > > Reflectors will never reflect any packets with state as "UP". > > > However the only issue is the use of state field differently i.e. > > > state in the S-BFD control packet from initiator does not > > > reflect the local state which is anyway not significant at reflector. > > > > > > 3. Use of local discriminator as My Disc at reflector: > > > > > > Reflector will always fill in My Discriminator with a locally > > > allocated discriminator value (not reserved discriminators) and will > > > not copy it from the received packet. > > > > > > Please share your thoughts on the proposals. > > > > > > Thanks > > > > > > Regards > > > Mallik > > > > > > > > --_000_CF43569B1C305mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Good that we have some consensus to use D bit as the option. We will u= pdate the draft 03 with this and also list all other options discussed in t= he appendix so that all are aware of these. We will include the UDP port ba= sed solution suggested by Greg also.

Thanks

Regards
Mallik

From: <Bhatia>, "Manav (= Manav)" <manav.b= hatia@alcatel-lucent.com>
Date: Monday 10 March 2014 5:02 AM<= br> To: Santosh P K <santoshpk@juniper.net>, "Nobo Akiya (= nobo)" <nobo@cisco.com>, G= regory Mirsky <gregory.mi= rsky@ericsson.com>, Cisco Employee <mmudigon@cisco.co= m>, "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Hi Santosh,

Seamless BFD uses a new UDP port and that should be good enough to ove= rload the D bit. I don't  think we should be revising the version= number -- at least not based on what I have heard till now.

Cheers, Manav

-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Santosh P
K
Sent: Sunday, March 09, 2014 9:18 PM
To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudigon);
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
I prefer D-bit option too. Simply because it is clean. D-bit loses its=
meaning in S-BFD context and I don't think it will be used. Only
question is do we need to come up with a new version to use D-bit?
Thanks
Santosh P K
> -----Original Message-----
> From: Rtg-bfd [mailto= :rtg-bfd-bounces@ietf.org] On Behalf Of Nobo
Akiya
> (nobo)
> Sent: Sunday, March 09, 2014 7:03 PM
> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-b= ase)
>
> Hi Mallik, Greg, [S-]BFDers,
>
> Please see in-line.
>
> > -----Original Message-----
> > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> > Sent: Saturday, March 08, 2014 4:43 PM
> > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg-
> > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seaml= ess-
base)
> >
> > Dear Mallik, et. al,
> > apologies for being terribly behind on processing mail queue= .
> > I was to propose use of another well-known UDP port for S-BF= D but
then
> > I looked closer at RFC 5881.
>
> S-BFD proposes to use a new well-known UDP port (starting from ba= se-
02 ...
> sorry doc is still not very clear, but we've done major facelift = on -
03, which is to
> be submitted after loop/security discussions). And since differen= t
UDP ports,
> even if were to change meaning of some fields of BFD control head= er
(ex: D bit
> interpretation), I don't feel that up versioning is absolutely
required. We could,
> but we could also avoid.
>
> > I think that we may use UDP source port of S- BFD packet rec= eived
by a
> > reflector as UDP destination  port in reflected pa= cket to break the
> > spoofed loop.
>
> Regarding usage of source UDP port to break the loop, true that's=
another
> possibility. This should definitely be listed as one of the optio= ns.
It would require
> that (dest UDP port !=3D src UDP port) ... and solution is outsid= e of
BFD control
> header (do we ever want to do IP-less?).
>
> > If not that, then Option #1 but with new version (I think we= 'll
need
> > new version # anyway).
>
> I'm glad to see that you also prefer option #1. I recommend we mo= ve
forward
> with this, but list all other options in the appendix and keep th= e
discussion open
> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, = what
do you
> think?
>
> -Nobo
>
> >
> > Regards,
> > Greg
> >
> > -----Original Message-----
> > From: Rtg-bfd [m= ailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo
> > Akiya
> > (nobo)
> > Sent: Saturday, March 08, 2014 10:46 AM
> > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
> > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seaml= ess-
base)
> >
> > Hi Mallik, et al,
> >
> > My preference:
> >
> > 1 > 2 > 3
> >
> > Reasons:
> >
> > [3] Deviating discriminator by reflector session - Proposed = will
> > prevent a single S-BFD session to speak to multiple reflecto= rs
(cannot
> > do reply demux'ing), if implementation wants to do this or i= f there
is
> > ever such use- case.
> >
> > [2] State - No strong opposition here, but just looks cleane= r for
> > S-BFD initiator to reflect session state in state field of p= ackets
sent.
> >
> > [1] D bit - I can't think of any reason why S-BFD initiator = wants
to
> > set D bit in packet to reflector session that is stateless. = If S-
BFD
> > initiator is not interested in receiving back any response, = S-BFD
> > initiator can simply "not send". Thus, there is no= issue with
changing
> > the meaning of D bit in S-BFD context.
> >
> > -Nobo
> >
> > > -----Original Message-----
> > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
MALLIK
> > > MUDIGONDA (mmudigon)
> > > Sent: Friday, March 07, 2014 7:58 AM
> > > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seam= less-base)
> > >
> > >
> > > Hi,
> > >
> > > Loop prevention
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > > Description:
> > >
> > > Consider a scenario where we have two nodes and both ar= e S-BFD
capable.
> > >
> > >
> > >      Node A (IP 1.1.1.1) = ---------------- Node B (IP 2.2.2.2)
> > > |
> > > |
> > > Man in the Mi= ddle (MiM)
> > >
> > > Node A reserved discriminator 0x01010101 and will have = a
reflector
> > > session in listening mode. Similarly Node B reserved
discriminator
> > > 0x02020202 for its reflector session.
> > >
> > > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01= 010101,
> > YourDisc
> > > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2= .2.2. When
this
> > > packet reaches Node B, the reflector session on Node B = will swap
the
> > > discriminators and IP addresses of the received packet = and
reflect
> > > it back, since YourDisc of the received packet matched = with
reserved
> > > discriminator of Node B. The reflected packet that reac= hed Node A
> > > will have
> > > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since Y= ourDisc of the
> > > received packet matched the reserved discriminator of N= ode A,
Node A
> > > will swap the discriminators and reflects the packet ba= ck to Node
B.
> > > Since reflectors MUST set the TTL of the reflected pack= ets to
255,
> > > the above scenario will result in an infinite loop with= just one
> > > malicious packet injected from MiM.
> > >
> > > FYI: Packet fields do not carry any direction informati= on, i.e.,
if
> > > this is Ping packet or reply packet.
> > >
> > > Solutions
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > > The current proposals are:
> > >
> > > 1. Overload "D" bit (Demand mode bit).
> > >
> > > In= itiator always sets the 'D' bit and reflector
clears it. This
> > way
> > > we can identify if a received packet was a reflected pa= cket
> > >         &n= bsp; and avoid reflecting it back. However this changes
the
> > > interpretation of 'D' bit.
> > >
> > > 2. Use of State field in the BFD control packets:
> > >
> > >      Initiator will always send packets with State set to
"DOWN"
> > > and reflector will send back packets with state field s= et to "UP.
> > > Re= flectors will never reflect any packets with state
as "UP".
> > > However the only issue is the use of state field differ= ently i.e.
> > >      state in the S-BFD control packet from initiator does
not
> > > reflect the local state which is anyway not significant= at
reflector.
> > >
> > > 3. Use of local discriminator as My Disc at reflector:
> > >
> > > Re= flector will always fill in My Discriminator with a
locally
> > > allocated discriminator value (not reserved discriminat= ors) and
will
> > > no= t copy it from the received packet.
> > >
> > > Please share your thoughts on the proposals.
> > >
> > > Thanks
> > >
> > > Regards
> > > Mallik
> > >
> > >
>
>


 --_000_CF43569B1C305mmudigonciscocom_-- From nobody Sun Mar 9 23:42:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB66F1A0316 for ; Sun, 9 Mar 2014 23:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNy-0mV8OYvu for ; Sun, 9 Mar 2014 23:42:50 -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 F09361A03CF for ; Sun, 9 Mar 2014 23:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16061; q=dns/txt; s=iport; t=1394433765; x=1395643365; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=4S9USKx5z5BrNlaPa7ys0CtU3aeGb9EX9tYIqY+vWOQ=; b=CsK2Dh7VDwo7+2AaAiAGzCVKxjO1hkXOoCHdSNxXKMdg0NyyODP3xVej yvMHXWbuVtFzERB/0ETdHqvxbc9uRFx0hxIOj01ikdu896JHh3Ly3zxH1 J1vkCtDl0VvX+YGIwxc9WDXnM8iibbOGTfbiRjOvg5RWElSQ6hEW5fRG3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FANxdHVOtJXG//2dsb2JhbABQCoJCRIESwTyBGBZ0giUBAQEEgQUGAQgRAwEBASgmExQJCAIEARIbh17PQheNfwsBAT4YBoQyBI5ziVKSLYMtgWkGAxci X-IronPort-AV: E=Sophos;i="4.97,622,1389744000"; d="scan'208,217";a="309138303" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 10 Mar 2014 06:42:43 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2A6ghnQ028393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 06:42:43 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 01:42:43 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Gregory Mirsky , "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIAC3rSA Date: Mon, 10 Mar 2014 06:42:42 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF435BF81C319mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Npca75qLjJtqXzBNZnCLDFg-5x4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 06:42:53 -0000 --_000_CF435BF81C319mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Yes, using source UDP port would be one of the options. But I have a questi= on here. Is it mandatory that we carry the Well Known UDP port (yet to be a= llocated for SBFD) as destination port in all packets including the reflect= ed ones? If yes, then we cannot swap the UDP ports but should use well know= n UDP port as destination and a local port as source port when reflecting p= ackets back to the initiator. In such a case the initiator will not be able= to use this to break the loop. Am I missing something? Thanks Regards Mallik From: Gregory Mirsky > Date: Sunday 9 March 2014 3:12 AM To: "Nobo Akiya (nobo)" >, Cisco Empl= oyee >, "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Dear Mallik, et. al, apologies for being terribly behind on processing mail queue. I was to propose use of another well-known UDP port for S-BFD but then I lo= oked closer at RFC 5881. I think that we may use UDP source port of S-BFD p= acket received by a reflector as UDP destination port in reflected packet = to break the spoofed loop. If not that, then Option #1 but with new version= (I think we'll need new version # anyway). Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Saturday, March 08, 2014 10:46 AM To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Mallik, et al, My preference: 1 > 2 > 3 Reasons: [3] Deviating discriminator by reflector session - Proposed will prevent a = single S-BFD session to speak to multiple reflectors (cannot do reply demux= 'ing), if implementation wants to do this or if there is ever such use-case= . [2] State - No strong opposition here, but just looks cleaner for S-BFD ini= tiator to reflect session state in state field of packets sent. [1] D bit - I can't think of any reason why S-BFD initiator wants to set D = bit in packet to reflector session that is stateless. If S-BFD initiator is= not interested in receiving back any response, S-BFD initiator can simply = "not send". Thus, there is no issue with changing the meaning of D bit in S= -BFD context. -Nobo -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon) Sent: Friday, March 07, 2014 7:58 AM To: rtg-bfd@ietf.org Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi, Loop prevention =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Description: Consider a scenario where we have two nodes and both are S-BFD capable. Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) | | Man in the Middle (MiM) Node A reserved discriminator 0x01010101 and will have a reflector session in listening mode. Similarly Node B reserved discriminator 0x02020202 for its reflector session. Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this packet reaches Node B, the reflector session on Node B will swap the discriminators and IP addresses of the received packet and reflect it back, since YourDisc of the received packet matched with reserved discriminator of Node B. The reflected packet that reached Node A will have MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the received packet matched the reserved discriminator of Node A, Node A will swap the discriminators and reflects the packet back to Node B. Since reflectors MUST set the TTL of the reflected packets to 255, the above scenario will result in an infinite loop with just one malicious packet injected from MiM. FYI: Packet fields do not carry any direction information, i.e., if this is Ping packet or reply packet. Solutions =3D=3D=3D=3D=3D=3D=3D=3D=3D The current proposals are: 1. Overload "D" bit (Demand mode bit). Initiator always sets the 'D' bit and reflector clears it. This way we can identify if a received packet was a reflected packet and avoid reflecting it back. However this changes the interpretation of 'D' bit. 2. Use of State field in the BFD control packets: Initiator will always send packets with State set to "DOWN" and reflector will send back packets with state field set to "UP. Reflectors will never reflect any packets with state as "UP". However the only issue is the use of state field differently i.e. state in the S-BFD control packet from initiator does not reflect the local state which is anyway not significant at reflector. 3. Use of local discriminator as My Disc at reflector: Reflector will always fill in My Discriminator with a locally allocated discriminator value (not reserved discriminators) and will not copy it from the received packet. Please share your thoughts on the proposals. Thanks Regards Mallik --_000_CF435BF81C319mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7D7AE3933BB1AF4F9BFCC043F06B62DD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

Yes, using source UDP port would be one of the options. But I have a q= uestion here. Is it mandatory that we carry the Well Known UDP port (yet to= be allocated for SBFD) as destination port in all packets including the re= flected ones? If yes, then we cannot swap the UDP ports but should use well known UDP port as destination and a= local port as source port when reflecting packets back to the initiator. I= n such a case the initiator will not be able to use this to break the loop.= Am I missing something?

Thanks

Regards
Mallik

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Sunday 9 March 2014 3:12 AM To: "Nobo Akiya (nobo)" &= lt;nobo@cisco.com>, Cisco Employee= <mmudigon@cisco.com>, &quo= t;rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Dear Mallik, et. al,
apologies for being terribly behind on processing mail queue.
I was to propose use of another well-known UDP port for S-BFD but then= I looked closer at RFC 5881. I think that we may use UDP source port of S-= BFD packet received by a reflector as UDP destination  port in re= flected packet to break the spoofed loop. If not that, then Option #1 but with new version (I think we'll need new v= ersion # anyway).

Regard= s,
Greg

-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
Sent: Saturday, March 08, 2014 10:46 AM
To: MALLIK MUDIGONDA (mmudigon); r= tg-bfd@ietf.org
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

[3] Deviating discriminator by reflector session - Proposed will preve= nt a single S-BFD session to speak to multiple reflectors (cannot do reply = demux'ing), if implementation wants to do this or if there is ever such use= -case.

[2] State - No strong opposition here, but just looks cleaner for S-BF= D initiator to reflect session state in state field of packets sent.
[1] D bit - I can't think of any reason why S-BFD initiator wants to s= et D bit in packet to reflector session that is stateless. If S-BFD initiat= or is not interested in receiving back any response, S-BFD initiator can si= mply "not send". Thus, there is no issue with changing the meaning of D bit in S-BFD context.

-Nobo

-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of MALLIK
MUDIGONDA (mmudigon)
Sent: Friday, March 07, 2014 7:58 AM
Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
Hi,
Loop prevention
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Description:
Consider a scenario where we have two nodes and both are S-BFD capable= .
      Node A (IP 1.1.1.1) --------------= -- Node B (IP 2.2.2.2)
|
|
Man in the Middle (MiM)
Node A reserved discriminator 0x01010101 and will have a reflector
session in listening mode. Similarly Node B reserved discriminator
0x02020202 for its reflector session.
Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDis= c
=3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this=
packet reaches Node B, the reflector session on Node B will swap the <= /div>
discriminators and IP addresses of the received packet and reflect it =
back, since YourDisc of the received packet matched with reserved
discriminator of Node B. The reflected packet that reached Node A will=
have
MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the =
received packet matched the reserved discriminator of Node A, Node A <= /div>
will swap the discriminators and reflects the packet back to Node B. <= /div>
Since reflectors MUST set the TTL of the reflected packets to 255, the=
above scenario will result in an infinite loop with just one malicious=
packet injected from MiM.
FYI: Packet fields do not carry any direction information, i.e., if
this is Ping packet or reply packet.
Solutions
=3D=3D=3D=3D=3D=3D=3D=3D=3D
The current proposals are:
1. Overload "D" bit (Demand mode bit).
Initiator always = sets the 'D' bit and reflector clears it. This way
we can identify if a received packet was a reflected packet
           and avoid reflecting= it back. However this changes the
interpretation of 'D' bit.
2. Use of State field in the BFD control packets:
 =     Initiator will always send packets with State set to "DOWN"= ;
and reflector will send back packets with state field set to "UP.=
Reflectors will n= ever reflect any packets with state as "UP".
However the only issue is the use of state field differently i.e.
 =     state in the S-BFD control packet from initiator does not
reflect the local state which is anyway not significant at reflector.<= /div>
3. Use of local discriminator as My Disc at reflector:
Reflector will al= ways fill in My Discriminator with a locally
allocated discriminator value (not reserved discriminators) and will
not copy it from = the received packet.
Please share your thoughts on the proposals.
Thanks
Regards
Mallik


--_000_CF435BF81C319mmudigonciscocom_-- From nobody Sun Mar 9 23:50:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8F11A03D5 for ; Sun, 9 Mar 2014 23:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w38CDEuK9fok for ; Sun, 9 Mar 2014 23:50:30 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 744F51A03CF for ; Sun, 9 Mar 2014 23:50:30 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s2A6oLUO029346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Mar 2014 01:50:22 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s2A6oJUN017700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 02:50:21 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 10 Mar 2014 02:50:20 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Mon, 10 Mar 2014 14:49:58 +0800 From: "Bhatia, Manav (Manav)" To: "MALLIK MUDIGONDA (mmudigon)" , Gregory Mirsky , "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIAC3rSA//9QG0A= Date: Mon, 10 Mar 2014 06:49:57 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5A7DF7@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> 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.17] Content-Type: multipart/alternative; boundary="_000_20211F91F544D247976D84C5D778A4C32E5A7DF7SG70YWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qfBjq7g3HCrFNidGCs25XU4y3ZI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 06:50:34 -0000 --_000_20211F91F544D247976D84C5D778A4C32E5A7DF7SG70YWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, You can check for UDP ports only if a well known UDP port is NOT assigned t= o S-BFD. The current draft proposes using a well known UDP port. In that case we wil= l use the "D" bit to avoid the loop. Cheers, Manav From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Monday, March 10, 2014 12:13 PM To: Gregory Mirsky; Nobo Akiya (nobo); rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Greg, Yes, using source UDP port would be one of the options. But I have a questi= on here. Is it mandatory that we carry the Well Known UDP port (yet to be a= llocated for SBFD) as destination port in all packets including the reflect= ed ones? If yes, then we cannot swap the UDP ports but should use well know= n UDP port as destination and a local port as source port when reflecting p= ackets back to the initiator. In such a case the initiator will not be able= to use this to break the loop. Am I missing something? Thanks Regards Mallik From: Gregory Mirsky > Date: Sunday 9 March 2014 3:12 AM To: "Nobo Akiya (nobo)" >, Cisco Empl= oyee >, "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Dear Mallik, et. al, apologies for being terribly behind on processing mail queue. I was to propose use of another well-known UDP port for S-BFD but then I lo= oked closer at RFC 5881. I think that we may use UDP source port of S-BFD p= acket received by a reflector as UDP destination port in reflected packet = to break the spoofed loop. If not that, then Option #1 but with new version= (I think we'll need new version # anyway). Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Saturday, March 08, 2014 10:46 AM To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Mallik, et al, My preference: 1 > 2 > 3 Reasons: [3] Deviating discriminator by reflector session - Proposed will prevent a = single S-BFD session to speak to multiple reflectors (cannot do reply demux= 'ing), if implementation wants to do this or if there is ever such use-case= . [2] State - No strong opposition here, but just looks cleaner for S-BFD ini= tiator to reflect session state in state field of packets sent. [1] D bit - I can't think of any reason why S-BFD initiator wants to set D = bit in packet to reflector session that is stateless. If S-BFD initiator is= not interested in receiving back any response, S-BFD initiator can simply = "not send". Thus, there is no issue with changing the meaning of D bit in S= -BFD context. -Nobo -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon) Sent: Friday, March 07, 2014 7:58 AM To: rtg-bfd@ietf.org Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi, Loop prevention =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Description: Consider a scenario where we have two nodes and both are S-BFD capable. Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) | | Man in the Middle (MiM) Node A reserved discriminator 0x01010101 and will have a reflector session in listening mode. Similarly Node B reserved discriminator 0x02020202 for its reflector session. Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this packet reaches Node B, the reflector session on Node B will swap the discriminators and IP addresses of the received packet and reflect it back, since YourDisc of the received packet matched with reserved discriminator of Node B. The reflected packet that reached Node A will have MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the received packet matched the reserved discriminator of Node A, Node A will swap the discriminators and reflects the packet back to Node B. Since reflectors MUST set the TTL of the reflected packets to 255, the above scenario will result in an infinite loop with just one malicious packet injected from MiM. FYI: Packet fields do not carry any direction information, i.e., if this is Ping packet or reply packet. Solutions =3D=3D=3D=3D=3D=3D=3D=3D=3D The current proposals are: 1. Overload "D" bit (Demand mode bit). Initiator always sets the 'D' bit and reflector clears it. This way we can identify if a received packet was a reflected packet and avoid reflecting it back. However this changes the interpretation of 'D' bit. 2. Use of State field in the BFD control packets: Initiator will always send packets with State set to "DOWN" and reflector will send back packets with state field set to "UP. Reflectors will never reflect any packets with state as "UP". However the only issue is the use of state field differently i.e. state in the S-BFD control packet from initiator does not reflect the local state which is anyway not significant at reflector. 3. Use of local discriminator as My Disc at reflector: Reflector will always fill in My Discriminator with a locally allocated discriminator value (not reserved discriminators) and will not copy it from the received packet. Please share your thoughts on the proposals. Thanks Regards Mallik --_000_20211F91F544D247976D84C5D778A4C32E5A7DF7SG70YWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik,

 

You can check for UDP ports only if a well known UDP port is NOT assigned= to S-BFD.

 

The current draft proposes using a well known UDP port. In that case we w= ill use the “D” bit to avoid the loop.

 

Cheers, Manav

 

 

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Monday, March 10, 2014 12:13 PM
To: Gregory Mirsky; Nobo Akiya (nobo); rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hi Greg,

 

Yes, using source UDP port would be one of the options. But I = have a question here. Is it mandatory that we carry the Well Known UDP port= (yet to be allocated for SBFD) as destination port in all packets including the reflected ones?= If yes, then we cannot swap the UDP ports but should use well known UDP po= rt as destination and a local port as source port when reflecting packets b= ack to the initiator. In such a case the initiator will not be able to use this to break the loop. Am I mi= ssing something?

 

Thanks

 

Regards

Mallik

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Sunday 9 March 2014 3:12 AM
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, Cisco Employee <mmudigon@cisco.com>, "rtg-bfd@ietf.org" <rtg= -bfd@ietf.org>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Dear Mallik, et. al,

apologies for being terribly behind on processing mail queue.<= o:p>

I was to propose use of another well-known UDP port for S-BFD = but then I looked closer at RFC 5881. I think that we may use UDP source po= rt of S-BFD packet received by a reflector as UDP destination  port in reflected packet to b= reak the spoofed loop. If not that, then Option #1 but with new version (I = think we'll need new version # anyway).

 

Regards,

Greg

 

-----Original Message-----

From: Rtg-bfd [mai= lto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo)=

Sent: Saturday, March 08, 2014 10:46 AM

To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org<= /p>

Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamles= s-base)

 

Hi Mallik, et al,

 

My preference:

 

1 > 2 > 3

 

Reasons:

 

[3] Deviating discriminator by reflector session - Proposed wi= ll prevent a single S-BFD session to speak to multiple reflectors (cannot d= o reply demux'ing), if implementation wants to do this or if there is ever such use-case.

 

[2] State - No strong opposition here, but just looks cleaner = for S-BFD initiator to reflect session state in state field of packets sent= .

[1] D bit - I can't think of any reason why S-BFD initiator wa= nts to set D bit in packet to reflector session that is stateless. If S-BFD= initiator is not interested in receiving back any response, S-BFD initiator can simply "not send&= quot;. Thus, there is no issue with changing the meaning of D bit in S-BFD = context.

 

-Nobo

 

-----Original Message-----

From: Rtg-bfd [mai= lto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK

MUDIGONDA (mmudigon)

Sent: Friday, March 07, 2014 7:58 AM

To: rtg-bfd@ietf.org<= /p>

Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-ba= se)

Hi,

Loop prevention

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Description:

Consider a scenario where we have two nodes and both are S-BFD= capable.

      Node A (IP 1.1.1.1) ------= ---------- Node B (IP 2.2.2.2)

|

|

Man in the Middle (MiM)

Node A reserved discriminator 0x01010101 and will have a refle= ctor

session in listening mode. Similarly Node B reserved discrimin= ator

0x02020202 for its reflector session.

Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101,= YourDisc

=3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. W= hen this

packet reaches Node B, the reflector session on Node B will sw= ap the

discriminators and IP addresses of the received packet and ref= lect it

back, since YourDisc of the received packet matched with reser= ved

discriminator of Node B. The reflected packet that reached Nod= e A will

have

MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc= of the

received packet matched the reserved discriminator of Node A, = Node A

will swap the discriminators and reflects the packet back to N= ode B.

Since reflectors MUST set the TTL of the reflected packets to = 255, the

above scenario will result in an infinite loop with just one m= alicious

packet injected from MiM.

FYI: Packet fields do not carry any direction information, i.e= ., if

this is Ping packet or reply packet.

Solutions

=3D=3D=3D=3D=3D=3D=3D=3D=3D

The current proposals are:

1.

Overload "D" bit (Demand mode bit).

Initiator always sets the 'D' bit and reflector clears it. Thi= s way

we can identify if a received packet was a reflected packet

           and avoid reflecting it back. However this changes the

interpretation of 'D' bit.

2.

Use of State field in the BFD control packets:

    

Initiator will always send packets with State set to "DOW= N"

and reflector will send back packets with state field set to &= quot;UP.

Reflectors will never reflect any packets with state as "= UP".

However the only issue is the use of state field differently i= .e.

    

state in the S-BFD control packet from initiator does not

reflect the local state which is anyway not significant at ref= lector.

3.

Use of local discriminator as My Disc at reflector:=

Reflector will always fill in My Discriminator with a locally

allocated discriminator value (not reserved discriminators) an= d will

not copy it from the received packet.

Please share your thoughts on the proposals.=

Thanks

Regards

Mallik

 

 

--_000_20211F91F544D247976D84C5D778A4C32E5A7DF7SG70YWXCHMBA05z_-- From nobody Sun Mar 9 23:55:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370741A03DA for ; Sun, 9 Mar 2014 23:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CLGlrRm62eg for ; Sun, 9 Mar 2014 23:55:09 -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 710D51A03D5 for ; Sun, 9 Mar 2014 23:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13709; q=dns/txt; s=iport; t=1394434504; x=1395644104; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=3a9aE/H+T//5IwwthJkVNFOTbdpK8xkTNZ+OQXIMekU=; b=SEaHim55YXYGbkxqjys8uQiSrMLBuJQUn0Jz+EYuZGQ3hzWUkbwNY0eE Fvo2IwnIByNnBViCzTE5qpmUvJe9eC2kl/YOCnCKvX3PMS/zLxaVvj+v4 uWr79CQTB2e8vh02v+mtVO+pP+Qz3QJ1Kzp7CdjKGsZDfls9Xr/EbDm9w w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAJhgHVOtJXG//2dsb2JhbABQCoJCRIESwTyBGRZ0giUBAQEEgQUGAQgRAwEBASgmExQJCAIEARIbh17PRBeNf0sYBoQyBI5ziVKSLYMtgWkGPA X-IronPort-AV: E=Sophos;i="4.97,622,1389744000"; d="scan'208,217";a="309148268" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 10 Mar 2014 06:55:03 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2A6t3Z4004699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Mar 2014 06:55:03 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 01:55:03 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAxBiAA== Date: Mon, 10 Mar 2014 06:55:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF435EB51C325mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/w-coop7dOReDZjcQLVnxMJuc6Io X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 06:55:12 -0000 --_000_CF435EB51C325mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, My replies inline Regards Mallik From: "Nobo Akiya (nobo)" > Date: Sunday 9 March 2014 12:16 AM To: Cisco Employee >, "rtg-bf= d@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Mallik, et al, My preference: 1 > 2 > 3 Reasons: [3] Deviating discriminator by reflector session - Proposed will prevent a = single S-BFD session to speak to multiple reflectors (cannot do reply demux= 'ing), if implementation wants to do this or if there is ever such use-case= . Mallik Even in this case, Reflectors need not use different discriminators = for different initiators. They can still use the same discriminator for all= reflected packets. Is there a problem here? The other point about reply de= muxing, even the base BFD draft specifies that myDisc can change for a sess= ion and that yourDisc should be used for de-multiplexing. Am I missing some= point? [2] State - No strong opposition here, but just looks cleaner for S-BFD ini= tiator to reflect session state in state field of packets sent. [1] D bit - I can't think of any reason why S-BFD initiator wants to set D = bit in packet to reflector session that is stateless. If S-BFD initiator is= not interested in receiving back any response, S-BFD initiator can simply = "not send". Thus, there is no issue with changing the meaning of D bit in S= -BFD context. -Nobo -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon) Sent: Friday, March 07, 2014 7:58 AM To: rtg-bfd@ietf.org Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi, Loop prevention =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Description: Consider a scenario where we have two nodes and both are S-BFD capable. Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) | | Man in the Middle (MiM) Node A reserved discriminator 0x01010101 and will have a reflector session in listening mode. Similarly Node B reserved discriminator 0x02020202 for its reflector session. Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this pack= et reaches Node B, the reflector session on Node B will swap the discriminators and IP addresses of the received packet and reflect it back, since YourDisc of the received packet matched with reserved discriminator of Node B. The reflected packet that reached Node A will have MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the received packet matched the reserved discriminator of Node A, Node A will swap the discriminators and reflects the packet back to Node B. Since reflectors MUST set the TTL of the reflected packets to 255, the above scenario will result in an infinite loop with just one malicious packet injected from MiM. FYI: Packet fields do not carry any direction information, i.e., if this is= Ping packet or reply packet. Solutions =3D=3D=3D=3D=3D=3D=3D=3D=3D The current proposals are: 1. Overload "D" bit (Demand mode bit). Initiator always sets the 'D' bit and reflector clears it. This way we can identify if a received packet was a reflected packet and avoid reflecting it back. However this changes the interpretation of 'D' bit. 2. Use of State field in the BFD control packets: Initiator will always send packets with State set to "DOWN" and reflector will send back packets with state field set to "UP. Reflectors will never reflect any packets with state as "UP". However the only issue is the use of state field differently i.e. state in the S-BFD control packet from initiator does not reflect the local state which is anyway not significant at reflector. 3. Use of local discriminator as My Disc at reflector: Reflector will always fill in My Discriminator with a locally allocated discriminator value (not reserved discriminators) and will not copy it from the received packet. Please share your thoughts on the proposals. Thanks Regards Mallik --_000_CF435EB51C325mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Nobo,

My replies inline

Regards
Mallik

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Sunday 9 March 2014 12:16 AM<= br> To: Cisco Employee <mmudigon@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

[3] Deviating discriminator by reflector session - Proposed will preve= nt a single S-BFD session to speak to multiple reflectors (cannot do reply = demux'ing), if implementation wants to do this or if there is ever such use= -case.

Mallik Even in this case, Reflectors need not use different discrimina= tors for different initiators. They can still use the same discriminator fo= r all reflected packets. Is there a problem here? The other point about rep= ly demuxing, even the base BFD draft specifies that myDisc can change for a session and that yourDisc should be= used for de-multiplexing. Am I missing some point?

[2] State - No strong opposition here, but just looks cleaner for S-BF= D initiator to reflect session state in state field of packets sent.
[1] D bit - I can't think of any reason why S-BFD initiator wants to s= et D bit in packet to reflector session that is stateless. If S-BFD initiat= or is not interested in receiving back any response, S-BFD initiator can si= mply "not send". Thus, there is no issue with changing the meaning of D bit in S-BFD context.

-Nobo

-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of MALLIK
MUDIGONDA (mmudigon)
Sent: Friday, March 07, 2014 7:58 AM
Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
Hi,
Loop prevention
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Description:
Consider a scenario where we have two nodes and both are S-BFD capable= .
      Node A (IP 1.1.1.1) --------------= -- Node B (IP 2.2.2.2)
|
|
Man in the Middle (MiM)
Node A reserved discriminator 0x01010101 and will have a reflector ses= sion
in listening mode. Similarly Node B reserved discriminator 0x02020202 = for
its reflector session.
Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDis= c
=3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this= packet
reaches Node B, the reflector session on Node B will swap the
discriminators and IP addresses of the received packet and reflect it = back,
since YourDisc of the received packet matched with reserved discrimina= tor
of Node B. The reflected packet that reached Node A will have
MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the<= /div>
received packet matched the reserved discriminator of Node A, Node A w= ill
swap the discriminators and reflects the packet back to Node B. Since<= /div>
reflectors MUST set the TTL of the reflected packets to 255, the above=
scenario will result in an infinite loop with just one malicious packe= t
injected from MiM.
FYI: Packet fields do not carry any direction information, i.e., if th= is is Ping
packet or reply packet.
Solutions
=3D=3D=3D=3D=3D=3D=3D=3D=3D
The current proposals are:
1. Overload "D" bit (Demand mode bit).
Initiator always = sets the 'D' bit and reflector clears it. This
way we can identify if a received packet was a reflected packet
           and avoid reflecting= it back. However this changes the
interpretation of 'D' bit.
2. Use of State field in the BFD control packets:
 =     Initiator will always send packets with State set to "DOWN"= ;
and reflector will send back packets with state field set to "UP.=
Reflectors will n= ever reflect any packets with state as "UP".
However the only issue is the use of state field differently i.e.
 =     state in the S-BFD control packet from initiator does not
reflect the local state which is anyway not significant at reflector.<= /div>
3. Use of local discriminator as My Disc at reflector:
Reflector will al= ways fill in My Discriminator with a locally
allocated discriminator value (not reserved discriminators) and will
not copy it from = the received packet.
Please share your thoughts on the proposals.
Thanks
Regards
Mallik


 --_000_CF435EB51C325mmudigonciscocom_-- From nobody Mon Mar 10 00:23:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2B81A02A3 for ; Mon, 10 Mar 2014 00:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5iCceCue00r for ; Mon, 10 Mar 2014 00:23:53 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id BD5EA1A03EF for ; Mon, 10 Mar 2014 00:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9197; q=dns/txt; s=iport; t=1394436226; x=1395645826; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=B4fegm93gj/FgtbeiEKfYyX8HaKDHTLYi1IPGYDa/a0=; b=GNKirxebb5PPbf+e8njlunVDIYo+Z2wWyxkp4lECtLPbNN5LcqcSoCTN BnG77YB3A5FwRskX+fhqGiMPQe0jYzKwXLC/va4SfFbdbScAXyZ35TEV2 IoIlPN0Y+ycEOhOIVWvEHvjPuoaVDUyT75KZIZIwb5e9kWlFR7LgVN9jF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAF9nHVOtJV2a/2dsb2JhbABQCoMGgRLBPIEZFnSCJQEBAQQnE0sEAgEIEQQBAQsUCQcyFAkIAgQBEggTh17PSReNfwsBAR44BoMegRQBA6pygy2BaQYDFyI X-IronPort-AV: E=Sophos;i="4.97,622,1389744000"; d="scan'208";a="26166878" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 10 Mar 2014 07:23:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2A7Nkst007193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 07:23:46 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 02:23:45 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "Bhatia, Manav (Manav)" , Santosh P K , "Nobo Akiya (nobo)" , Gregory Mirsky , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMA Date: Mon, 10 Mar 2014 07:23:45 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/yYjRISwRqJ1deHT5ZkUq9cYmy8Y X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 07:23:56 -0000 Hello Manav/ all, I beg to differ here - while BFD relies on using UDP port numbers to demu= x packet types (Async or Echo), there is currently no notion of interpretin= g bits differently based on UDP destination port numbers. IMHO, it may be c= leaner to consider defining a packet format of S-BFD Async afresh instead o= f re-defining BFD Async [RFC5880], while still using the UDP destination po= rt to demux the packet type. This could provide an opportunity to revisit t= he entire Async header to reclaim/ add additional bit(s). Two candidates co= uld be (a) the M bit which was intended for P2MP sessions (the Initiator ->= Reflector model proposed by S-BFD is already MP2P) (b) the RequiredMinEchoR= xInterval given that S-BFD defines Async only.=20 PS> The above two candidates are mere examples to make the case for redefin= ing the header and not proposals by themselves. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav = (Manav) Sent: Monday, March 10, 2014 5:02 AM To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudi= gon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Santosh, Seamless BFD uses a new UDP port and that should be good enough to overload= the D bit. I don't think we should be revising the version number -- at l= east not based on what I have heard till now. Cheers, Manav > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Sunday, March 09, 2014 9:18 PM > To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudigon);=20 > rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > I prefer D-bit option too. Simply because it is clean. D-bit loses its=20 > meaning in S-BFD context and I don't think it will be used. Only=20 > question is do we need to come up with a new version to use D-bit? >=20 > Thanks > Santosh P K >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > Akiya > > (nobo) > > Sent: Sunday, March 09, 2014 7:03 PM > > To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD=20 > > (draft-akiya-bfd-seamless-base) > > > > Hi Mallik, Greg, [S-]BFDers, > > > > Please see in-line. > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Saturday, March 08, 2014 4:43 PM > > > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- > bfd@ietf.org > > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > base) > > > > > > Dear Mallik, et. al, > > > apologies for being terribly behind on processing mail queue. > > > I was to propose use of another well-known UDP port for S-BFD but > then > > > I looked closer at RFC 5881. > > > > S-BFD proposes to use a new well-known UDP port (starting from base- > 02 ... > > sorry doc is still not very clear, but we've done major facelift on=20 > > - > 03, which is to > > be submitted after loop/security discussions). And since different > UDP ports, > > even if were to change meaning of some fields of BFD control header > (ex: D bit > > interpretation), I don't feel that up versioning is absolutely > required. We could, > > but we could also avoid. > > > > > I think that we may use UDP source port of S- BFD packet received > by a > > > reflector as UDP destination port in reflected packet to break=20 > > > the spoofed loop. > > > > Regarding usage of source UDP port to break the loop, true that's > another > > possibility. This should definitely be listed as one of the options. > It would require > > that (dest UDP port !=3D src UDP port) ... and solution is outside of > BFD control > > header (do we ever want to do IP-less?). > > > > > If not that, then Option #1 but with new version (I think we'll > need > > > new version # anyway). > > > > I'm glad to see that you also prefer option #1. I recommend we move > forward > > with this, but list all other options in the appendix and keep the > discussion open > > for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers,=20 > > what > do you > > think? > > > > -Nobo > > > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo=20 > > > Akiya > > > (nobo) > > > Sent: Saturday, March 08, 2014 10:46 AM > > > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > base) > > > > > > Hi Mallik, et al, > > > > > > My preference: > > > > > > 1 > 2 > 3 > > > > > > Reasons: > > > > > > [3] Deviating discriminator by reflector session - Proposed will=20 > > > prevent a single S-BFD session to speak to multiple reflectors > (cannot > > > do reply demux'ing), if implementation wants to do this or if=20 > > > there > is > > > ever such use- case. > > > > > > [2] State - No strong opposition here, but just looks cleaner for=20 > > > S-BFD initiator to reflect session state in state field of packets > sent. > > > > > > [1] D bit - I can't think of any reason why S-BFD initiator wants > to > > > set D bit in packet to reflector session that is stateless. If S- > BFD > > > initiator is not interested in receiving back any response, S-BFD=20 > > > initiator can simply "not send". Thus, there is no issue with > changing > > > the meaning of D bit in S-BFD context. > > > > > > -Nobo > > > > > > > -----Original Message----- > > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > MALLIK > > > > MUDIGONDA (mmudigon) > > > > Sent: Friday, March 07, 2014 7:58 AM > > > > To: rtg-bfd@ietf.org > > > > Subject: Loop Prevention in S-BFD=20 > > > > (draft-akiya-bfd-seamless-base) > > > > > > > > > > > > Hi, > > > > > > > > Loop prevention > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Description: > > > > > > > > Consider a scenario where we have two nodes and both are S-BFD > capable. > > > > > > > > > > > > Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > > > > | > > > > | > > > > Man in the Middle (MiM) > > > > > > > > Node A reserved discriminator 0x01010101 and will have a > reflector > > > > session in listening mode. Similarly Node B reserved > discriminator > > > > 0x02020202 for its reflector session. > > > > > > > > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, > > > YourDisc > > > > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When > this > > > > packet reaches Node B, the reflector session on Node B will swap > the > > > > discriminators and IP addresses of the received packet and > reflect > > > > it back, since YourDisc of the received packet matched with > reserved > > > > discriminator of Node B. The reflected packet that reached Node=20 > > > > A will have > > > > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of=20 > > > > the received packet matched the reserved discriminator of Node=20 > > > > A, > Node A > > > > will swap the discriminators and reflects the packet back to=20 > > > > Node > B. > > > > Since reflectors MUST set the TTL of the reflected packets to > 255, > > > > the above scenario will result in an infinite loop with just one=20 > > > > malicious packet injected from MiM. > > > > > > > > FYI: Packet fields do not carry any direction information, i.e., > if > > > > this is Ping packet or reply packet. > > > > > > > > Solutions > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > The current proposals are: > > > > > > > > 1. Overload "D" bit (Demand mode bit). > > > > > > > > Initiator always sets the 'D' bit and reflector > clears it. This > > > way > > > > we can identify if a received packet was a reflected packet > > > > and avoid reflecting it back. However this changes > the > > > > interpretation of 'D' bit. > > > > > > > > 2. Use of State field in the BFD control packets: > > > > > > > > Initiator will always send packets with State set to > "DOWN" > > > > and reflector will send back packets with state field set to "UP. > > > > Reflectors will never reflect any packets with state > as "UP". > > > > However the only issue is the use of state field differently i.e. > > > > state in the S-BFD control packet from initiator does > not > > > > reflect the local state which is anyway not significant at > reflector. > > > > > > > > 3. Use of local discriminator as My Disc at reflector: > > > > > > > > Reflector will always fill in My Discriminator with a > locally > > > > allocated discriminator value (not reserved discriminators) and > will > > > > not copy it from the received packet. > > > > > > > > Please share your thoughts on the proposals. > > > > > > > > Thanks > > > > > > > > Regards > > > > Mallik > > > > > > > > > > > > >=20 From nobody Mon Mar 10 05:18:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25A1A042F for ; Mon, 10 Mar 2014 05:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvFRTbWHuM7R for ; Mon, 10 Mar 2014 05:18:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4C31A0433 for ; Mon, 10 Mar 2014 05:18:26 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-0b-531dab3b8c16 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.67.12743.B3BAD135; Mon, 10 Mar 2014 13:08:27 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 08:18:18 -0400 From: Gregory Mirsky To: "MALLIK MUDIGONDA (mmudigon)" , "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIAC3rSA//+mKuA= Date: Mon, 10 Mar 2014 12:18:18 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B778974@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B778974eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXRPoK71atlgg/XHpSyOvDrGbDG7I97i 859tjA7MHlN+b2T1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxuPODSwFVyYxVSw6L9vA+OYLYxcj J4eEgInEoebJzBC2mMSFe+vZuhi5OIQEjjBKzNq+FspZzijRva+ZBaSKTcBI4sXGHnaQhIhA K6PEmpZZYKOEBVwl3j+dC2aLCLhJ3Hs0nxXC9pO4eBIiziKgKrHh53kwm1fAV+LJnV4mEFtI oFhi5q9VQEM5ODgFDCQmtUqAhBmBLvp+ag1YCbOAuMStJ/OZIC4VkFiy5zzU1aISLx//Y4Ww lSTmvL7GDFGfLzG79wo7xCpBiZMzn7BMYBSZhWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnG PnPgMROy+AJG9lWMHKXFqWW56UYGmxiBkXRMgk13B+Oel5aHGKU5WJTEeb+8dQ4SEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwGgteO5mgetuDyn74w0MrpMkbj6zP2t9/+Q5xu3WzeYCrq7h r3KWtXyStlN5+X7yEpX2WdPcKu+pTg+x7b21I1Bo2n2f/+dtZvv0lk+t0A75N/n/Bu2HawLa 8wT27d5zNi05TkBNh3Mqj8ry1UbTVrt5bngxcdL0Pjn+xXsXeXh63VzTJsk0p1OJpTgj0VCL uag4EQDyw+I5cgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/HNDSyur3A2dYTHPy0k92i4qlxTM X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 12:18:42 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B778974eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, et. al, I'd assume that S-BFD Sender, node that initiates S-BFD session, would use = dynamic UDP port as its UDP source port while UDP destination port required= to be set to well-known value. RFC 5880 doesn't make firm requirements on = use of UDP source port number. I think that recommendations made in the RFC= 5880 are quite favorable for S-BFD and can be re-used. Use of S-BFD well-k= nown UDP port as source by Reflector seemed reasonable to me but we can cer= tainly discuss if it useful. But I think that there might be one aspect of selection of UDP ports that I= 'd like to discuss. In many sets of OAM Requirements we find requirement to= ensure OAM being in-band with user traffic. That is problematic if there's= ECMP. Hence my question, would we take upon S-BFD in-band requirement or l= eave it out of scope of base specification. I'm raising this question since= UDP port numbers, destination and source, usually used to produce hash for= ECMP distribution. Regards, Greg From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Sunday, March 09, 2014 11:43 PM To: Gregory Mirsky; Nobo Akiya (nobo); rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Greg, Yes, using source UDP port would be one of the options. But I have a questi= on here. Is it mandatory that we carry the Well Known UDP port (yet to be a= llocated for SBFD) as destination port in all packets including the reflect= ed ones? If yes, then we cannot swap the UDP ports but should use well know= n UDP port as destination and a local port as source port when reflecting p= ackets back to the initiator. In such a case the initiator will not be able= to use this to break the loop. Am I missing something? Thanks Regards Mallik From: Gregory Mirsky > Date: Sunday 9 March 2014 3:12 AM To: "Nobo Akiya (nobo)" >, Cisco Empl= oyee >, "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Dear Mallik, et. al, apologies for being terribly behind on processing mail queue. I was to propose use of another well-known UDP port for S-BFD but then I lo= oked closer at RFC 5881. I think that we may use UDP source port of S-BFD p= acket received by a reflector as UDP destination port in reflected packet = to break the spoofed loop. If not that, then Option #1 but with new version= (I think we'll need new version # anyway). Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Saturday, March 08, 2014 10:46 AM To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Mallik, et al, My preference: 1 > 2 > 3 Reasons: [3] Deviating discriminator by reflector session - Proposed will prevent a = single S-BFD session to speak to multiple reflectors (cannot do reply demux= 'ing), if implementation wants to do this or if there is ever such use-case= . [2] State - No strong opposition here, but just looks cleaner for S-BFD ini= tiator to reflect session state in state field of packets sent. [1] D bit - I can't think of any reason why S-BFD initiator wants to set D = bit in packet to reflector session that is stateless. If S-BFD initiator is= not interested in receiving back any response, S-BFD initiator can simply = "not send". Thus, there is no issue with changing the meaning of D bit in S= -BFD context. -Nobo -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon) Sent: Friday, March 07, 2014 7:58 AM To: rtg-bfd@ietf.org Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi, Loop prevention =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Description: Consider a scenario where we have two nodes and both are S-BFD capable. Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) | | Man in the Middle (MiM) Node A reserved discriminator 0x01010101 and will have a reflector session in listening mode. Similarly Node B reserved discriminator 0x02020202 for its reflector session. Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this packet reaches Node B, the reflector session on Node B will swap the discriminators and IP addresses of the received packet and reflect it back, since YourDisc of the received packet matched with reserved discriminator of Node B. The reflected packet that reached Node A will have MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the received packet matched the reserved discriminator of Node A, Node A will swap the discriminators and reflects the packet back to Node B. Since reflectors MUST set the TTL of the reflected packets to 255, the above scenario will result in an infinite loop with just one malicious packet injected from MiM. FYI: Packet fields do not carry any direction information, i.e., if this is Ping packet or reply packet. Solutions =3D=3D=3D=3D=3D=3D=3D=3D=3D The current proposals are: 1. Overload "D" bit (Demand mode bit). Initiator always sets the 'D' bit and reflector clears it. This way we can identify if a received packet was a reflected packet and avoid reflecting it back. However this changes the interpretation of 'D' bit. 2. Use of State field in the BFD control packets: Initiator will always send packets with State set to "DOWN" and reflector will send back packets with state field set to "UP. Reflectors will never reflect any packets with state as "UP". However the only issue is the use of state field differently i.e. state in the S-BFD control packet from initiator does not reflect the local state which is anyway not significant at reflector. 3. Use of local discriminator as My Disc at reflector: Reflector will always fill in My Discriminator with a locally allocated discriminator value (not reserved discriminators) and will not copy it from the received packet. Please share your thoughts on the proposals. Thanks Regards Mallik --_000_7347100B5761DC41A166AC17F22DF1121B778974eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik, et. al,

I’d assume that S-B= FD Sender, node that initiates S-BFD session, would use dynamic UDP port as= its UDP source port while UDP destination port required to be set to well-known value. RFC 5880 doesn’t make firm requirements on = use of UDP source port number. I think that recommendations made in the RFC= 5880 are quite favorable for S-BFD and can be re-used. Use of S-BFD well-k= nown UDP port as source by Reflector seemed reasonable to me but we can certainly discuss if it useful.

But I think that there mi= ght be one aspect of selection of UDP ports that I’d like to discuss.= In many sets of OAM Requirements we find requirement to ensure OAM being in-band with user traffic. That is problematic if there’s = ECMP. Hence my question, would we take upon S-BFD in-band requirement or le= ave it out of scope of base specification. I’m raising this question = since UDP port numbers, destination and source, usually used to produce hash for ECMP distribution.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: MALLIK M= UDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Sunday, March 09, 2014 11:43 PM
To: Gregory Mirsky; Nobo Akiya (nobo); rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hi Greg,

 

Yes, using source UDP port wo= uld be one of the options. But I have a question here. Is it mandatory that= we carry the Well Known UDP port (yet to be allocated for SBFD) as destination port in all packets including the reflected ones? If = yes, then we cannot swap the UDP ports but should use well known UDP port a= s destination and a local port as source port when reflecting packets back = to the initiator. In such a case the initiator will not be able to use this to break the loop. Am I missing= something?

 

Thanks

 

Regards

Mallik

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Sunday 9 March 2014 3:12 AM
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, Cisco Employee <mmudigon@cisco.com>, "rtg-bfd@ietf.org" <rtg= -bfd@ietf.org>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Dear Mallik, et. al,

apologies for being terribly = behind on processing mail queue.

I was to propose use of anoth= er well-known UDP port for S-BFD but then I looked closer at RFC 5881. I th= ink that we may use UDP source port of S-BFD packet received by a reflector as UDP destination  port in reflected packet to b= reak the spoofed loop. If not that, then Option #1 but with new version (I = think we'll need new version # anyway).

 

Regards,

Greg

 

-----Original Message-----

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Nobo Akiya (nobo)

Sent: Saturday, March 08, 201= 4 10:46 AM

To: MALLIK MUDIGONDA (mmudigo= n); rtg-bfd@ietf.org<= /p>

Subject: RE: Loop Prevention = in S-BFD (draft-akiya-bfd-seamless-base)

 

Hi Mallik, et al,<= /span>

 

My preference:

 

1 > 2 > 3

 

Reasons:

 

[3] Deviating discriminator b= y reflector session - Proposed will prevent a single S-BFD session to speak= to multiple reflectors (cannot do reply demux'ing), if implementation wants to do this or if there is ever such use-case.

 

[2] State - No strong opposit= ion here, but just looks cleaner for S-BFD initiator to reflect session sta= te in state field of packets sent.

[1] D bit - I can't think of = any reason why S-BFD initiator wants to set D bit in packet to reflector se= ssion that is stateless. If S-BFD initiator is not interested in receiving back any response, S-BFD initiator can simply "not send&= quot;. Thus, there is no issue with changing the meaning of D bit in S-BFD = context.

 

-Nobo

 

-----Original Message-----

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of MALLIK

MUDIGONDA (mmudigon)

Sent: Friday, March 07, 2014 = 7:58 AM

To: rtg-bfd@ietf.org<= /p>

Subject: Loop Prevention in S= -BFD (draft-akiya-bfd-seamless-base)

Hi,

Loop prevention

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

Description:

Consider a scenario where we = have two nodes and both are S-BFD capable.

     = ; Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2)<= /span>

|

|

Man in the Middle (MiM)<= /o:p>

Node A reserved discriminator= 0x01010101 and will have a reflector

session in listening mode. Si= milarly Node B reserved discriminator

0x02020202 for its reflector = session.

Suppose MiM sends a spoofed p= acket with MyDisc =3D 0x01010101, YourDisc

=3D 0x02020202, source IP as = 1.1.1.1 and dest IP as 2.2.2.2. When this

packet reaches Node B, the re= flector session on Node B will swap the

discriminators and IP address= es of the received packet and reflect it

back, since YourDisc of the r= eceived packet matched with reserved

discriminator of Node B. The = reflected packet that reached Node A will

have

MyDdisc=3D0x02020202 and Your= Disc=3D0x01010101. Since YourDisc of the

received packet matched the r= eserved discriminator of Node A, Node A

will swap the discriminators = and reflects the packet back to Node B.

Since reflectors MUST set the= TTL of the reflected packets to 255, the

above scenario will result in= an infinite loop with just one malicious

packet injected from MiM.

FYI: Packet fields do not car= ry any direction information, i.e., if

this is Ping packet or reply = packet.

Solutions

=3D=3D=3D=3D=3D=3D=3D=3D=3D

The current proposals are:

1.

Overload "D" bit (D= emand mode bit).

Initiator always sets the 'D'= bit and reflector clears it. This way

we can identify if a received= packet was a reflected packet

     = ;      and avoid reflecting it back. However this changes the

interpretation of 'D' bit.

2.

Use of State field in the BFD= control packets:

    

Initiator will always send pa= ckets with State set to "DOWN"

and reflector will send back = packets with state field set to "UP.

Reflectors will never reflect= any packets with state as "UP".

However the only issue is the= use of state field differently i.e.

    

state in the S-BFD control pa= cket from initiator does not

reflect the local state which= is anyway not significant at reflector.

3.

Use of local discriminator as= My Disc at reflector:

Reflector will always fill in= My Discriminator with a locally

allocated discriminator value= (not reserved discriminators) and will

not copy it from the received= packet.

Please share your thoughts on= the proposals.

Thanks

Regards

Mallik

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B778974eusaamb103erics_-- From nobody Mon Mar 10 05:54:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D711A042D for ; Mon, 10 Mar 2014 05:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gNqZWLxjgvb for ; Mon, 10 Mar 2014 05:54:54 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 636531A0027 for ; Mon, 10 Mar 2014 05:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5263; q=dns/txt; s=iport; t=1394456089; x=1395665689; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UsdExXSZciTb43m+FV0ujhpiUqlEBs7lAOCJhSsh/yc=; b=GPxH261BcHlnnEUTmFeU/eygt3zezgekWu1yavsPJEoq/NMPrtM6NXO6 m1/ngoPqMYQ8953ulfUheTwuSuBUqJLAx+nmL6YL3ueajFXvQigoTjBf1 Cu6kWv+Oc1+YWaoYEdGuFqdp5gLho7jnctqTdAXr1DLl0KSS+tO4AgAV1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFABa1HVOtJV2b/2dsb2JhbABagmUhgRLBPIEaFnSCJQEBAQMBZwQaBAIBCBEDAQEBCx0HMhQJCAEBBAESCIdpCAHPXxeNeDIGMgaDHoEUBIkZoVmDLYIr X-IronPort-AV: E=Sophos;i="4.97,623,1389744000"; d="scan'208";a="309236584" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 10 Mar 2014 12:54:48 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2ACsm44015611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 12:54:48 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 07:54:48 -0500 From: "Nobo Akiya (nobo)" To: "Bhatia, Manav (Manav)" , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Security aspects with S-BFD Thread-Topic: Security aspects with S-BFD Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+GxeiW4sAABDK0AAAUoFLIAAbxZxA Date: Mon, 10 Mar 2014 12:54:47 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5A7AC9@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5A7AC9@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.61] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gCoK5T0B9NakjJ-0d_aCV5Nf3Vo X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 12:54:57 -0000 Hi Manav, > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Sunday, March 09, 2014 7:35 PM > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Security aspects with S-BFD >=20 > I agree with Nobo here. I don't think binding BFD with a timing protocol = is a > good idea. Glad to hear that! >=20 > > I think this is a general topic (i.e. applicable to both BFD and S-BFD)= that > > should continue to be discussed, and certainly would like to hear more > from BFD and KARP experts. >=20 > And pray what is that? What would you like to hear more about? I was hoping to see more on discussions around suggestions made by section = 6 of draft-ietf-karp-bfd-analysis-01 (for BFD and/or S-BFD), particularly u= sage of time in place of sequence number. That will be beneficial for one t= o make a call on embracing the suggestions. -Nobo >=20 > Cheers, Manav >=20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Friday, March 07, 2014 9:46 PM > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Security aspects with S-BFD >=20 > Good to see this discussion continuing (thank Mallik!). >=20 > I'm a bit skeptical of creating a hard dependency from BFD/S-BFD to time > synchronization protocol. Meaning, if we do this, malfunctions in the tim= e > synchronization protocol or even time drift can take down all BFD/S-BFD > sessions, causing instabilities in the network. >=20 > I think this is a general topic (i.e. applicable to both BFD and S-BFD) t= hat > should continue to be discussed, and certainly would like to hear more fr= om > BFD and KARP experts. >=20 > To progress S-BFD base draft, my vote would be to go with suggestion by > Manav (below) for the time being. >=20 > -Nobo >=20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > MUDIGONDA (mmudigon) > Sent: Friday, March 07, 2014 7:39 AM > To: rtg-bfd@ietf.org > Subject: Re: Security aspects with S-BFD >=20 > Hi, >=20 > As mentioned in =A0draft-ietf-karp-bfd-analysis-01=A0section 6, if we use= UTC > time for Sequence numbers (assuming Initiator and reflector are time > synchronized), then we can mitigate the problem of DOS and Replay attacks > at reflectors. Please share your thoughts. >=20 > Thanks >=20 > Regards > Mallik >=20 > From: , "Manav (Manav)" > Date: Thursday 7 November 2013 10:18 PM > To: "rtg-bfd@ietf.org" > Subject: Security aspects with S-BFD >=20 > Hi, >=20 > S-BFD describes the reflector sessions which raises interesting security > considerations. >=20 > Since the reflector sessions are stateless (that's one of the biggest > advantages) it's impossible for the reflector to keep track of the sequen= ce > number that its heard from its peers. This means, that the reflector is > susceptible to both inter-session and intra-session replay attacks. We ha= d a > discussion internally amongst the co-authors and had the following > proposal that we wanted to vet before the WG members. >=20 > Would like to hear the WGs opinion on this. >=20 > 1. The Initiator picks up a crypto sequence number depending upon the > authentication mode that its using (meticulous or non meticulous). It sen= ds > a packet to the Reflector with this seq num. >=20 > 2. The reflector maintains no session state and hence does not look at th= e > crypto sequence number before accepting the packet. It looks at the Key I= D > (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can= do it > based on its own database where it maps the neighbor to the key iD) and > verifies the authentication data. If everything looks good, it processes = the > packet. >=20 > 3. When responding the Reflector needs to compute the Authentication > data. It uses the same sequence number that it received in the S-BFD pack= et > that it is responding to. It knows the Key ID, and thus the SA. It comput= es > the authentication data and sends the S-BFD packet out. >=20 > 4. The Initiator receives the response from the Reflector. It only accept= s the > S-BFD packet if it either comes with the same sequence number as it had > sent or its within the window that it finds acceptable (described in deta= il in > Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) >=20 > Benefits of this scheme. >=20 > 1. Reflectors continue to remain stateless despite using security. >=20 > 2. Reflectors are not susceptible to replay attacks as they always respon= d to > S-BFD packets irrespective of the sequence number carried. >=20 > 3. An attacker cannot forge packets from the Reflector since the Initiato= r > will only accept S-BFD packets that come with the sequence number that it > had originally used when sending the S-BFD packet. >=20 > Drawbacks of this scheme. >=20 > 1. Reflectors are susceptible to DoS attacks since they respond to all > incoming S-BFD packets. This gets worse when cryptography is used as the > work load drastically increases as security is employed. >=20 > Cheers, Manav >=20 >=20 From nobody Mon Mar 10 06:18:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961291A0455 for ; Mon, 10 Mar 2014 06:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taPODPw0-mZ0 for ; Mon, 10 Mar 2014 06:18:02 -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 4374C1A045A for ; Mon, 10 Mar 2014 06:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5271; q=dns/txt; s=iport; t=1394457477; x=1395667077; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MESoj5Wc3uaWFeU11ru/Djzfwq263glCkkjG5ITe+B0=; b=O3z3qb1zdKdlnQg9gtPTyA6Dz9E2w0HCUz6j3nCnTCqwUYdiD34dAjYD 4ivJT48TNNJi/SQsK6+Dsy3I+o+gcu7rY0qiJD3wCpUNhRyp3OhI1qe94 q/enr7/rfeB+XT23m3pW5TiCVBV4sOqmB543W5bc7N3AX0eG/3Hzwi5kd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADq6HVOtJXHB/2dsb2JhbABQCoJnIYENvRuBGhYBdIN9AQEBBIEFBAIBCBEDAQEBCx0HMhQJCAIEARIIE4dpAcZEF442KzgGgx2BEwEDiQuhH4MrgWgGATs X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="306170285" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 10 Mar 2014 13:17:56 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2ADHu8b031943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Mar 2014 13:17:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 08:17:56 -0500 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAxBiAP//uE9g Date: Mon, 10 Mar 2014 13:17:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.61] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WLXQtLiuDsHEYkXsfPbwX6rR5l4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 13:18:08 -0000 Hi Mallik, Please see inline. > -----Original Message----- > From: MALLIK MUDIGONDA (mmudigon) > Sent: Monday, March 10, 2014 2:55 AM > To: Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Nobo, >=20 > My replies inline >=20 > Regards > Mallik >=20 > From: "Nobo Akiya (nobo)" > Date: Sunday 9 March 2014 12:16 AM > To: Cisco Employee , "rtg-bfd@ietf.org" bfd@ietf.org> > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Mallik, et al, >=20 > My preference: >=20 > 1 > 2 > 3 >=20 > Reasons: >=20 > [3] Deviating discriminator by reflector session - Proposed will prevent = a > single S-BFD session to speak to multiple reflectors (cannot do reply > demux'ing), if implementation wants to do this or if there is ever such u= se- > case. >=20 > Mallik Even in this case, Reflectors need not use different discriminator= s for > different initiators. They can still use the same discriminator for all > reflected packets. Is there a problem here? The other point about reply > demuxing, even the base BFD draft specifies that myDisc can change for a > session and that yourDisc should be used for de-multiplexing. Am I missin= g > some point? If a single initiator is to talk to multiple reflectors (a, b, c), then my_= discrim (x) may be the same for BFD packets sent to (a, b, c). When reply f= rom reflectors come back, then your_discrim cannot be used to demux as it w= ill be the same (x). Other demux candidates are source IP and dest UDP in t= he reply ... but I was pointing out that if reply had my_discrim as (a, b, = c), then that can be used to demux. Of course emphasis on "... if implement= ations wants to do this or if there is ever such use-case". -Nobo =20 >=20 > [2] State - No strong opposition here, but just looks cleaner for S-BFD > initiator to reflect session state in state field of packets sent. > [1] D bit - I can't think of any reason why S-BFD initiator wants to set = D bit in > packet to reflector session that is stateless. If S-BFD initiator is not > interested in receiving back any response, S-BFD initiator can simply "no= t > send". Thus, there is no issue with changing the meaning of D bit in S-BF= D > context. >=20 > -Nobo >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > MUDIGONDA (mmudigon) > Sent: Friday, March 07, 2014 7:58 AM > To: rtg-bfd@ietf.org > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > Hi, > Loop prevention > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Description: > Consider a scenario where we have two nodes and both are S-BFD capable. > =A0=A0=A0=A0=A0=A0Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2= ) > | > | > Man in the Middle (MiM) > Node A reserved discriminator 0x01010101 and will have a reflector sessio= n > in listening mode. Similarly Node B reserved discriminator 0x02020202 for > its reflector session. > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this pa= cket > reaches Node B, the reflector session on Node B will swap the > discriminators and IP addresses of the received packet and reflect it bac= k, > since YourDisc of the received packet matched with reserved discriminator > of Node B. The reflected packet that reached Node A will have > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the > received packet matched the reserved discriminator of Node A, Node A will > swap the discriminators and reflects the packet back to Node B. Since > reflectors MUST set the TTL of the reflected packets to 255, the above > scenario will result in an infinite loop with just one malicious packet > injected from MiM. > FYI: Packet fields do not carry any direction information, i.e., if this = is Ping > packet or reply packet. > Solutions > =3D=3D=3D=3D=3D=3D=3D=3D=3D > The current proposals are: > 1. Overload "D" bit (Demand mode bit). > Initiator always sets the 'D' bit and reflector clears it. This > way we can identify if a received packet was a reflected packet > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 and avoid reflecting it back. However this= changes the > interpretation of 'D' bit. > 2. Use of State field in the BFD control packets: > =A0=A0=A0=A0 Initiator will always send packets with State set to "DOWN= " > and reflector will send back packets with state field set to "UP. > Reflectors will never reflect any packets with state as "UP". > However the only issue is the use of state field differently i.e. > =A0=A0=A0=A0 state in the S-BFD control packet from initiator does not > reflect the local state which is anyway not significant at reflector. > 3. Use of local discriminator as My Disc at reflector: > Reflector will always fill in My Discriminator with a locally > allocated discriminator value (not reserved discriminators) and will > not copy it from the received packet. > Please share your thoughts on the proposals. > Thanks > Regards > Mallik >=20 From nobody Mon Mar 10 06:38:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D7B1A0434 for ; Mon, 10 Mar 2014 06:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6NEhOAei-Mk for ; Mon, 10 Mar 2014 06:38:29 -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 BC4BA1A042A for ; Mon, 10 Mar 2014 06:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8973; q=dns/txt; s=iport; t=1394458704; x=1395668304; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ealOpxIcTQu1phRE6cvdxFkP70zSF8F5j5t8TjW15FA=; b=brxbBRSkiJI5BrH88/OVyqZI0pV+uQP/msTIKCFJ+RD/rsGftnpDz55t +jKfQbAKuqczuaqduCUodul/pi9/rYP4KJueBZrBBF2AMtY4F45DyMRJl bHolCyEUchZ82Lys8QPLUxVZZbnRM91wMK5Rf3SOvkO/k9g+k3X+rXO0v 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFABm/HVOtJV2Z/2dsb2JhbABQCoJlIYESwTyBGhZ0giUBAQEDAX4HBAIBCBEDAQEBCx0HMhQJCAIEARIIE4dWCAHPZxeNfwsBAR44BoMegRQEiRmhWYMtgWkGAQIXIg X-IronPort-AV: E=Sophos;i="4.97,623,1389744000"; d="scan'208";a="309231494" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 10 Mar 2014 13:38:24 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2ADcNdi032764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 13:38:23 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 08:38:23 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" , "Bhatia, Manav (Manav) (manav.bhatia@alcatel-lucent.com)" , "Vengada Prasad Govindan (venggovi)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIAC3rSA//+mKuCAABoSQA== Date: Mon, 10 Mar 2014 13:38:22 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B778974@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B778974@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.61] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/JdhXWvIv_6FOr8_jPTQTF7ZxcxU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 13:38:33 -0000 Hi Greg, Mallik, Manav, Prasad, et al, We've had version number bump conversation before, it tends end ugly. Even = if we [all] were able to get passed that with warm-fuzzy-feeling, there'll = be strong possibility of feature creep. Thus, I prefer to not revisit the v= ersion number bump, until there's a necessity to do so which I don't see at= the moment. > I'd assume that S-BFD Sender, node that initiates S-BFD session, would us= e > dynamic UDP port as its UDP source port while UDP destination port > required to be set to well-known value. RFC 5880 doesn't make firm > requirements on use of UDP source port number. I think that > recommendations made in the RFC 5880 are quite favorable for S-BFD and > can be re-used. Use of S-BFD well-known UDP port as source by Reflector > seemed reasonable to me but we can certainly discuss if it useful. I agree, RFC5880 style of UDP port usage is favorable for S-BFD. > But I think that there might be one aspect of selection of UDP ports that= I'd > like to discuss. In many sets of OAM Requirements we find requirement to > ensure OAM being in-band with user traffic. That is problematic if there'= s > ECMP. Hence my question, would we take upon S-BFD in-band requirement > or leave it out of scope of base specification. I'm raising this question= since > UDP port numbers, destination and source, usually used to produce hash fo= r > ECMP distribution. The fact that we can't do this with BFD today keeps me up some nights. I ag= ree Greg, it would be a very nice problem to solve, but a very difficult on= e to solve at that, i.e. we would need flexibility in both UDP source and d= estination ports. For now, I'm relying on Entropy Label to pick up the slac= k on this front. If absolutely required w/o EL, it's still possible if all = nodes employed 3-tuple hashing. -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, March 10, 2014 8:18 AM > To: MALLIK MUDIGONDA (mmudigon); Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Mallik, et. al, > I'd assume that S-BFD Sender, node that initiates S-BFD session, would us= e > dynamic UDP port as its UDP source port while UDP destination port > required to be set to well-known value. RFC 5880 doesn't make firm > requirements on use of UDP source port number. I think that > recommendations made in the RFC 5880 are quite favorable for S-BFD and > can be re-used. Use of S-BFD well-known UDP port as source by Reflector > seemed reasonable to me but we can certainly discuss if it useful. > But I think that there might be one aspect of selection of UDP ports that= I'd > like to discuss. In many sets of OAM Requirements we find requirement to > ensure OAM being in-band with user traffic. That is problematic if there'= s > ECMP. Hence my question, would we take upon S-BFD in-band requirement > or leave it out of scope of base specification. I'm raising this question= since > UDP port numbers, destination and source, usually used to produce hash fo= r > ECMP distribution. >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Regards, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Greg >=20 > From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] > Sent: Sunday, March 09, 2014 11:43 PM > To: Gregory Mirsky; Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Greg, >=20 > Yes, using source UDP port would be one of the options. But I have a > question here. Is it mandatory that we carry the Well Known UDP port (yet > to be allocated for SBFD) as destination port in all packets including th= e > reflected ones? If yes, then we cannot swap the UDP ports but should use > well known UDP port as destination and a local port as source port when > reflecting packets back to the initiator. In such a case the initiator wi= ll not be > able to use this to break the loop. Am I missing something? >=20 > Thanks >=20 > Regards > Mallik >=20 > From: Gregory Mirsky > Date: Sunday 9 March 2014 3:12 AM > To: "Nobo Akiya (nobo)" , Cisco Employee > , "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Dear Mallik, et. al, > apologies for being terribly behind on processing mail queue. > I was to propose use of another well-known UDP port for S-BFD but then I > looked closer at RFC 5881. I think that we may use UDP source port of S-B= FD > packet received by a reflector as UDP destination=A0=A0port in reflected = packet to > break the spoofed loop. If not that, then Option #1 but with new version = (I > think we'll need new version # anyway). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Saturday, March 08, 2014 10:46 AM > To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Mallik, et al, >=20 > My preference: >=20 > 1 > 2 > 3 >=20 > Reasons: >=20 > [3] Deviating discriminator by reflector session - Proposed will prevent = a > single S-BFD session to speak to multiple reflectors (cannot do reply > demux'ing), if implementation wants to do this or if there is ever such u= se- > case. >=20 > [2] State - No strong opposition here, but just looks cleaner for S-BFD > initiator to reflect session state in state field of packets sent. > [1] D bit - I can't think of any reason why S-BFD initiator wants to set = D bit in > packet to reflector session that is stateless. If S-BFD initiator is not > interested in receiving back any response, S-BFD initiator can simply "no= t > send". Thus, there is no issue with changing the meaning of D bit in S-BF= D > context. >=20 > -Nobo >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > MUDIGONDA (mmudigon) > Sent: Friday, March 07, 2014 7:58 AM > To: rtg-bfd@ietf.org > Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > Hi, > Loop prevention > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Description: > Consider a scenario where we have two nodes and both are S-BFD capable. > =A0=A0=A0=A0=A0=A0Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2= ) > | > | > Man in the Middle (MiM) > Node A reserved discriminator 0x01010101 and will have a reflector > session in listening mode. Similarly Node B reserved discriminator > 0x02020202 for its reflector session. > Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, YourDisc > =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this > packet reaches Node B, the reflector session on Node B will swap the > discriminators and IP addresses of the received packet and reflect it > back, since YourDisc of the received packet matched with reserved > discriminator of Node B. The reflected packet that reached Node A will > have > MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of the > received packet matched the reserved discriminator of Node A, Node A > will swap the discriminators and reflects the packet back to Node B. > Since reflectors MUST set the TTL of the reflected packets to 255, the > above scenario will result in an infinite loop with just one malicious > packet injected from MiM. > FYI: Packet fields do not carry any direction information, i.e., if > this is Ping packet or reply packet. > Solutions > =3D=3D=3D=3D=3D=3D=3D=3D=3D > The current proposals are: > 1. > Overload "D" bit (Demand mode bit). > Initiator always sets the 'D' bit and reflector clears it. This way > we can identify if a received packet was a reflected packet > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 and avoid reflecting it back. However this= changes the > interpretation of 'D' bit. > 2. > Use of State field in the BFD control packets: >=20 > Initiator will always send packets with State set to "DOWN" > and reflector will send back packets with state field set to "UP. > Reflectors will never reflect any packets with state as "UP". > However the only issue is the use of state field differently i.e. >=20 > state in the S-BFD control packet from initiator does not > reflect the local state which is anyway not significant at reflector. > 3. > Use of local discriminator as My Disc at reflector: > Reflector will always fill in My Discriminator with a locally > allocated discriminator value (not reserved discriminators) and will > not copy it from the received packet. > Please share your thoughts on the proposals. > Thanks > Regards > Mallik >=20 From nobody Mon Mar 10 08:48:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A5F1A04AA; Mon, 10 Mar 2014 08:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsVO7XZhkNQM; Mon, 10 Mar 2014 08:48:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E884F1A043E; Mon, 10 Mar 2014 08:48:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-intervals-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140310154835.19057.51146.idtracker@ietfa.amsl.com> Date: Mon, 10 Mar 2014 08:48:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2fV_guPrfRcZqQnXrETqq9GaB9g Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 15:48:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Common Interval Support in BFD Authors : Nobo Akiya Marc Binderberger Greg Mirsky Filename : draft-ietf-bfd-intervals-00.txt Pages : 9 Date : 2014-03-10 Abstract: Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common interval value to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-intervals-00 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 nobody Mon Mar 10 15:26:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAC91A04D2 for ; Mon, 10 Mar 2014 15:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiTzKhJAD88z for ; Mon, 10 Mar 2014 15:26:20 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 358651A04B1 for ; Mon, 10 Mar 2014 15:26:19 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 9DCB52AA0F; Mon, 10 Mar 2014 22:26:10 +0000 (GMT) Date: Mon, 10 Mar 2014 15:26:10 -0700 From: Marc Binderberger To: Vengada Prasad Govindan (venggovi) , Nobo Akiya (nobo) Message-ID: <20140310152610918599.225ad953@sniff.de> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/mHPL-BeuELWfZde4inEfKxJMZNI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 22:26:23 -0000 Hello Prasad, Nobo et al., > IMHO, it may be cleaner to consider defining a packet format > of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], > while still using the UDP destination port to demux the packet type. Maybe this is the main point: by re-using the D bit it would not be the RFC5880 packet anymore but a different packet (albeit a small difference). And looking into the Demand parts of 5880 I don't think reusing "Demand" for S-BFD will fit well. One could go back (must go back?) to RFC5880 and declare that the D bit definition depends on the session type, leave it otherwise undefined in RFC5880 and re-define today's (D)emand use in RFC5881. And the new use in the S-BFD document. That would be cleaner, IMHO. But is also a prohibitive amount of work. (the software change for generic CPU to re-interpret the D bit for S-BFD is likely trivial. I like this aspect. Not so sure about your NP though. And your ASIC may need a re-spin. It's always the same problem with re-defining something that is already defined). For the introduction of a new version - I got fierce rejection when I proposed it a while ago :-) . We probably would want to introduce more changes then, remember the "want more flags" discussion we had. > [3] Deviating discriminator by reflector session - Proposed will > prevent a single S-BFD session to speak to multiple reflectors > (cannot do reply demux'ing), if implementation wants to do this or if > there is ever such use-case. I admit I haven't understood the "speak to multiple reflector" part. How would this work, the reflector is defined by the your_discr of the outgoing packet, so how can multiple reflectors react on the BFD packet (?). Some kind of multicast or multipoint transport with a "multicast discriminator"? Regards, Marc On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govindan (venggovi) wrote: > Hello Manav/ all, > I beg to differ here - while BFD relies on using UDP port numbers > to demux packet types (Async or Echo), there is currently no notion > of interpreting bits differently based on UDP destination port > numbers. IMHO, it may be cleaner to consider defining a packet format > of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], > while still using the UDP destination port to demux the packet type. > This could provide an opportunity to revisit the entire Async header > to reclaim/ add additional bit(s). Two candidates could be (a) the M > bit which was intended for P2MP sessions (the Initiator ->Reflector > model proposed by S-BFD is already MP2P) (b) the > RequiredMinEchoRxInterval given that S-BFD defines Async only. > PS> The above two candidates are mere examples to make the case for > redefining the header and not proposals by themselves. > Thanks > Prasad > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, > Manav (Manav) > Sent: Monday, March 10, 2014 5:02 AM > To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA > (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > Hi Santosh, > > Seamless BFD uses a new UDP port and that should be good enough to > overload the D bit. I don't think we should be revising the version > number -- at least not based on what I have heard till now. > > Cheers, Manav > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P >> K >> Sent: Sunday, March 09, 2014 9:18 PM >> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); >> rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> I prefer D-bit option too. Simply because it is clean. D-bit loses its >> meaning in S-BFD context and I don't think it will be used. Only >> question is do we need to come up with a new version to use D-bit? >> >> Thanks >> Santosh P K >> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >> Akiya >>> (nobo) >>> Sent: Sunday, March 09, 2014 7:03 PM >>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org >>> Subject: RE: Loop Prevention in S-BFD >>> (draft-akiya-bfd-seamless-base) >>> >>> Hi Mallik, Greg, [S-]BFDers, >>> >>> Please see in-line. >>> >>>> -----Original Message----- >>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>>> Sent: Saturday, March 08, 2014 4:43 PM >>>> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- >> bfd@ietf.org >>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >> base) >>>> >>>> Dear Mallik, et. al, >>>> apologies for being terribly behind on processing mail queue. >>>> I was to propose use of another well-known UDP port for S-BFD but >> then >>>> I looked closer at RFC 5881. >>> >>> S-BFD proposes to use a new well-known UDP port (starting from base- >> 02 ... >>> sorry doc is still not very clear, but we've done major facelift on >>> - >> 03, which is to >>> be submitted after loop/security discussions). And since different >> UDP ports, >>> even if were to change meaning of some fields of BFD control header >> (ex: D bit >>> interpretation), I don't feel that up versioning is absolutely >> required. We could, >>> but we could also avoid. >>> >>>> I think that we may use UDP source port of S- BFD packet received >> by a >>>> reflector as UDP destination port in reflected packet to break >>>> the spoofed loop. >>> >>> Regarding usage of source UDP port to break the loop, true that's >> another >>> possibility. This should definitely be listed as one of the options. >> It would require >>> that (dest UDP port != src UDP port) ... and solution is outside of >> BFD control >>> header (do we ever want to do IP-less?). >>> >>>> If not that, then Option #1 but with new version (I think we'll >> need >>>> new version # anyway). >>> >>> I'm glad to see that you also prefer option #1. I recommend we move >> forward >>> with this, but list all other options in the appendix and keep the >> discussion open >>> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, >>> what >> do you >>> think? >>> >>> -Nobo >>> >>>> >>>> Regards, >>>> Greg >>>> >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>> Akiya >>>> (nobo) >>>> Sent: Saturday, March 08, 2014 10:46 AM >>>> To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org >>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >> base) >>>> >>>> Hi Mallik, et al, >>>> >>>> My preference: >>>> >>>> 1 > 2 > 3 >>>> >>>> Reasons: >>>> >>>> [3] Deviating discriminator by reflector session - Proposed will >>>> prevent a single S-BFD session to speak to multiple reflectors >> (cannot >>>> do reply demux'ing), if implementation wants to do this or if >>>> there >> is >>>> ever such use- case. >>>> >>>> [2] State - No strong opposition here, but just looks cleaner for >>>> S-BFD initiator to reflect session state in state field of packets >> sent. >>>> >>>> [1] D bit - I can't think of any reason why S-BFD initiator wants >> to >>>> set D bit in packet to reflector session that is stateless. If S- >> BFD >>>> initiator is not interested in receiving back any response, S-BFD >>>> initiator can simply "not send". Thus, there is no issue with >> changing >>>> the meaning of D bit in S-BFD context. >>>> >>>> -Nobo >>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >> MALLIK >>>>> MUDIGONDA (mmudigon) >>>>> Sent: Friday, March 07, 2014 7:58 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Loop Prevention in S-BFD >>>>> (draft-akiya-bfd-seamless-base) >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Loop prevention >>>>> =============== >>>>> >>>>> Description: >>>>> >>>>> Consider a scenario where we have two nodes and both are S-BFD >> capable. >>>>> >>>>> >>>>> Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) >>>>> | >>>>> | >>>>> Man in the Middle (MiM) >>>>> >>>>> Node A reserved discriminator 0x01010101 and will have a >> reflector >>>>> session in listening mode. Similarly Node B reserved >> discriminator >>>>> 0x02020202 for its reflector session. >>>>> >>>>> Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, >>>> YourDisc >>>>> = 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When >> this >>>>> packet reaches Node B, the reflector session on Node B will swap >> the >>>>> discriminators and IP addresses of the received packet and >> reflect >>>>> it back, since YourDisc of the received packet matched with >> reserved >>>>> discriminator of Node B. The reflected packet that reached Node >>>>> A will have >>>>> MyDdisc=0x02020202 and YourDisc=0x01010101. Since YourDisc of >>>>> the received packet matched the reserved discriminator of Node >>>>> A, >> Node A >>>>> will swap the discriminators and reflects the packet back to >>>>> Node >> B. >>>>> Since reflectors MUST set the TTL of the reflected packets to >> 255, >>>>> the above scenario will result in an infinite loop with just one >>>>> malicious packet injected from MiM. >>>>> >>>>> FYI: Packet fields do not carry any direction information, i.e., >> if >>>>> this is Ping packet or reply packet. >>>>> >>>>> Solutions >>>>> ========= >>>>> >>>>> The current proposals are: >>>>> >>>>> 1. Overload "D" bit (Demand mode bit). >>>>> >>>>> Initiator always sets the 'D' bit and reflector >> clears it. This >>>> way >>>>> we can identify if a received packet was a reflected packet >>>>> and avoid reflecting it back. However this changes >> the >>>>> interpretation of 'D' bit. >>>>> >>>>> 2. Use of State field in the BFD control packets: >>>>> >>>>> Initiator will always send packets with State set to >> "DOWN" >>>>> and reflector will send back packets with state field set to "UP. >>>>> Reflectors will never reflect any packets with state >> as "UP". >>>>> However the only issue is the use of state field differently i.e. >>>>> state in the S-BFD control packet from initiator does >> not >>>>> reflect the local state which is anyway not significant at >> reflector. >>>>> >>>>> 3. Use of local discriminator as My Disc at reflector: >>>>> >>>>> Reflector will always fill in My Discriminator with a >> locally >>>>> allocated discriminator value (not reserved discriminators) and >> will >>>>> not copy it from the received packet. >>>>> >>>>> Please share your thoughts on the proposals. >>>>> >>>>> Thanks >>>>> >>>>> Regards >>>>> Mallik >>>>> >>>>> >>> >>> >> > From nobody Mon Mar 10 15:42:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03AF1A0495 for ; Mon, 10 Mar 2014 15:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0cKBuXa85CR for ; Mon, 10 Mar 2014 15:42:37 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 622061A04E8 for ; Mon, 10 Mar 2014 15:42:36 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8E03C2AA0F; Mon, 10 Mar 2014 22:42:29 +0000 (GMT) Date: Mon, 10 Mar 2014 15:42:30 -0700 From: Marc Binderberger To: "rtg-bfd@ietf.org" Message-ID: <20140310154230169637.2df3ccb1@sniff.de> In-Reply-To: <20140310154835.19057.51146.idtracker@ietfa.amsl.com> References: <20140310154835.19057.51146.idtracker@ietfa.amsl.com> Subject: Re: I-D Action: draft-ietf-bfd-intervals-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/psJ2MO5Wl1TwEJdveSfl4OnFweI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 22:42:40 -0000 Hello BFD experts, we submitted an updated version, now as workgroup draft. What are the changes: * changed wording as this is an informational draft. No "must" but "should", "recommended" and such. Instead of "Standard Interval Set" it's a "Common Interval Set". So nobody is forced but encouraged instead ;-) * the Common Interval Set contains: 3.3, 10, 20, 50, 100msec, 1sec. Outside the Common Set but proposed as larger value is 10sec. This set reflects several requests: consider the Y.1731 intervals so implementations can reuse code/hardware. And focus on a higher density (and smaller step width) for the lower interval values to blend nicely with software-based de-facto interval values Feedback - as always - welcome! Best regards, Marc On Mon, 10 Mar 2014 08:48:35 -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Bidirectional Forwarding Detection > Working Group of the IETF. > > Title : Common Interval Support in BFD > Authors : Nobo Akiya > Marc Binderberger > Greg Mirsky > Filename : draft-ietf-bfd-intervals-00.txt > Pages : 9 > Date : 2014-03-10 > > Abstract: > Some BFD implementations may be restricted to only support several > interval values. When such BFD implementations speak to each other, > there is a possibility of two sides not being able to find a common > interval value to run BFD sessions. > > This document defines a small set of interval values for BFD that we > call "Common intervals", and recommends implementations to support > the defined intervals. This solves the problem of finding an > interval value that both BFD speakers can support while allowing a > simplified implementation as seen for hardware-based BFD. It does > not restrict an implementation from supporting more intervals in > addition to the Common intervals. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-intervals-00 > > > 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 nobody Mon Mar 10 20:20:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067A41A03AC for ; Mon, 10 Mar 2014 20:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVABWILgjh2j for ; Mon, 10 Mar 2014 20:20:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 62ED91A04F6 for ; Mon, 10 Mar 2014 20:20:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBY15213; Tue, 11 Mar 2014 03:20:27 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Mar 2014 03:19:42 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Mar 2014 03:20:26 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 11:20:22 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAxBiAP//uE9ggADkopA= Date: Tue, 11 Mar 2014 03:20:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/43y1aUVTxNCSJc-QaZz5hHxp6to X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 03:20:38 -0000 Hi Nobo, Sorry to chime in... > > > > [3] Deviating discriminator by reflector session - Proposed will > > prevent a single S-BFD session to speak to multiple reflectors (cannot > > do reply demux'ing), if implementation wants to do this or if there is > > ever such use- case. > > > > Mallik Even in this case, Reflectors need not use different > > discriminators for different initiators. They can still use the same > > discriminator for all reflected packets. Is there a problem here? The > > other point about reply demuxing, even the base BFD draft specifies > > that myDisc can change for a session and that yourDisc should be used > > for de-multiplexing. Am I missing some point? >=20 > If a single initiator is to talk to multiple reflectors (a, b, c), then m= y_discrim (x) > may be the same for BFD packets sent to (a, b, c). When reply from reflec= tors I'd recommend not to allow the same my_discrim for multiple reflectors. Con= sider that there are scenarios that multiple S-BFD sessions between the sam= e initiator and reflector, where it requires that the my_discrim should be = different for different session. Although the same my_discrim for different= reflectiors is techniall workable, this may make the implementation comple= x.=20 Best regards, Mach > come back, then your_discrim cannot be used to demux as it will be the sa= me (x). > Other demux candidates are source IP and dest UDP in the reply ... but I = was > pointing out that if reply had my_discrim as (a, b, c), then that can be = used to > demux. Of course emphasis on "... if implementations wants to do this or = if there > is ever such use-case". >=20 From nobody Tue Mar 11 00:58:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCF71A03D7 for ; Tue, 11 Mar 2014 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YFA8Hn00qsl for ; Tue, 11 Mar 2014 00:57:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4D751A024B for ; Tue, 11 Mar 2014 00:57:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEL19798; Tue, 11 Mar 2014 07:57:51 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Mar 2014 07:57:02 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Mar 2014 07:57:50 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 15:57:48 +0800 From: Mach Chen To: "rtg-bfd@ietf.org" Subject: Question abouth P bit setting Thread-Topic: Question abouth P bit setting Thread-Index: Ac88/5dFi5viacsrTWOzMz5Bed6N9A== Date: Tue, 11 Mar 2014 07:57:47 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ajWFIoCYRtEIVwJvcaCICiI6yZc X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 07:57:59 -0000 Hi BFDers, Section 6.8.3. Timer Manipulation (RFC5880), second paragraph states: "If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated (see section 6.5). If the timing is such that a system receiving a Poll Sequence wishes to change the parameters described in this paragraph, the new parameter values MAY be carried in packets with the Final (F) bit set, even if the Poll Sequence has not yet been sent." According to the above statement, does it mean that one system of a BFD ses= sion will always send control packet with P bit set when the BFD session be= comes UP from DOWN state ? Because during the DOWN->UP period, the bfd.Desi= redMinTxInterval and bfd.RequiredMinRxInterval will be changed. Thanks, Mach From nobody Tue Mar 11 03:02:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF311A0707 for ; Tue, 11 Mar 2014 03:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LALdnX9AqsL4 for ; Tue, 11 Mar 2014 03:02:06 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 407281A0564 for ; Tue, 11 Mar 2014 03:02:06 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so5444135lan.2 for ; Tue, 11 Mar 2014 03:02:00 -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=KWrhSaX15Pc8woR0x/VZzxd3SFhMcQRvo4B2ax3wonM=; b=TmJYlGyuYeb6InD1MI8fCKRZU1hjBEdcgNsUxNpLezn8+Rv4ORN+aa5oujVmCCMQDm 6uE4vC+RLAKAji/MNGZFYq8wLbkT9D6mfiajA9CM1xBZ7vClDzxaUzMnsCqO0bcet++U xRlPnnPgIPv6IUjAj6piXTqFmhEUIaSBdFfTE+PWbjXTbetbmBd7KS05zKrTCelmNxE9 qIEDn6gru2zHJi3ub3ssz0d1f0GLBeDAGkx4GvYpFJDdSUPyNTAxWrbaehhVTEkSf17V CwDthB884C54OTLJk/rD+3d8khgiWMl9oL8umnhLHX8Wis/8gPmZvkgbEF+VV+TG+Eob zeiA== MIME-Version: 1.0 X-Received: by 10.112.131.34 with SMTP id oj2mr1138199lbb.43.1394532120018; Tue, 11 Mar 2014 03:02:00 -0700 (PDT) Received: by 10.114.2.1 with HTTP; Tue, 11 Mar 2014 03:01:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 12:01:59 +0200 Message-ID: Subject: Re: Question abouth P bit setting From: Binny Jeshan To: Mach Chen Content-Type: multipart/alternative; boundary=047d7b343ba6a4437304f451cfd1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dkHwJV3bF8lxD3aLqoS1qNs6n9U Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 10:02:10 -0000 --047d7b343ba6a4437304f451cfd1 Content-Type: text/plain; charset=ISO-8859-1 Hi Mach, During this phase the P Bit must not be set. P Bit has to be set only when the Timers are Changed from the Configuration "After the First negotiation was already done and the session was continuing to work". P Bit is as simple as to tell the peer to either 1) Enter the Re-negotiate phase again 2) Observe parameter changes (may be auth / other etc)... In your case, the session when it goes DOWN, it Moves its timers to a "Slow Interval" which is a standard >= 1 second value. This is known to the peer that in a DOWN session state the remote would operate in Slower interval and the peer system need not worry on what exact timer its using because in DOWN state the Peer is not going to observe for any defects, but just wait for the next UP packet only. Is this clear now? Please let us know if any further questions. Regards, Binny. On 11 March 2014 09:57, Mach Chen wrote: > Hi BFDers, > > > Section 6.8.3. Timer Manipulation (RFC5880), second paragraph states: > > "If either bfd.DesiredMinTxInterval is changed or > bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be > initiated (see section 6.5). If the timing is such that a system > receiving a Poll Sequence wishes to change the parameters described > in this paragraph, the new parameter values MAY be carried in packets > with the Final (F) bit set, even if the Poll Sequence has not yet > been sent." > > According to the above statement, does it mean that one system of a BFD > session will always send control packet with P bit set when the BFD session > becomes UP from DOWN state ? Because during the DOWN->UP period, the > bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval will be changed. > > Thanks, > Mach > > --047d7b343ba6a4437304f451cfd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mach,

During this phase t= he P Bit=A0=A0 must not be set. P Bit has to be set only when the Timers ar= e Changed from the Configuration "After the First negotiation was alre= ady done and the session was continuing to work". P Bit is as simple a= s to tell the peer to either 1) Enter the Re-negotiate=A0phase again 2) Obs= erve parameter changes (may be auth / other etc)... =A0

In your case, the session when it goes DOWN, it Moves i= ts timers to a "Slow Interval" which is a standard >=3D 1 seco= nd value. This is known to the peer that in a DOWN session state the remote= would operate in Slower interval and the peer system need not worry on wha= t exact timer its using because=A0in DOWN state the Peer is not going to ob= serve for any defects, but just wait for the next UP packet only.

Is this clear now? Please let us know if any further qu= estions.

Regards,
Binny.


On 11 March 2014 = 09:57, Mach Chen <mach.chen@huawei.com> wrote:
Hi BFDers,


Section 6.8.3. =A0Timer Manipulation (RFC5880), second paragraph states:
"If either bfd.DesiredMinTxInterval is changed or
=A0 =A0bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
=A0 =A0initiated (see section 6.5). =A0If the timing is such that a system<= br> =A0 =A0receiving a Poll Sequence wishes to change the parameters described<= br> =A0 =A0in this paragraph, the new parameter values MAY be carried in packet= s
=A0 =A0with the Final (F) bit set, even if the Poll Sequence has not yet =A0 =A0been sent."

According to the above statement, does it mean that one system of a BFD ses= sion will always send control packet with P bit set when the BFD session be= comes UP from DOWN state ? Because during the DOWN->UP period, the bfd.D= esiredMinTxInterval and =A0 bfd.RequiredMinRxInterval will be changed.

Thanks,
Mach


--047d7b343ba6a4437304f451cfd1-- From nobody Tue Mar 11 07:27:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD361A0458 for ; Tue, 11 Mar 2014 07:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_CPvoRsBBrS for ; Tue, 11 Mar 2014 07:27:49 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 152321A045D for ; Tue, 11 Mar 2014 07:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15102; q=dns/txt; s=iport; t=1394548063; x=1395757663; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=T1aX+6XuefbpDNAOFTFM5n6aO83K8ntwu722g8vZ+Sw=; b=S4bpkZajOLJiYOfl08kEUtBNUaIAW9ropmBxPTKDLry5LtQBxkjeIDjv 0ZW7DGooZZcf5wb++D9AU2INRuh2fO9YD70NFxm7d/tQIp7/2wPHoGQAJ wW8q2e06rdx+LkfHGO49ElT//l/N3/9pk6YzJB+Xuhvd0z5kZv7kAp/3E s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAH8cH1OtJXG9/2dsb2JhbABQCoJlIYESvUODc4EeFnSCJQEBAQMBJxM/BQcEAgEIEQQBAQEKFAkHMhQJCAIEAQ0FCBOHVggB0SMXjgALAQEeMQcGgx6BFAEDqnKDLYFpBgMXIg X-IronPort-AV: E=Sophos;i="4.97,631,1389744000"; d="scan'208";a="26568167" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-5.cisco.com with ESMTP; 11 Mar 2014 14:27:42 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2BERg3L028435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 14:27:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 09:27:42 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , "Vengada Prasad Govindan (venggovi)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QA== Date: Tue, 11 Mar 2014 14:27:41 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> In-Reply-To: <20140310152610918599.225ad953@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uqK6-0gDaPP1W0F9ke-a2WjYeuQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 14:27:52 -0000 Hi Marc, Mach, Thanks for comments! Combining the responses into a single thread. [Marc wrote] > > [3] Deviating discriminator by reflector session - Proposed will > > prevent a single S-BFD session to speak to multiple reflectors (cannot > > do reply demux'ing), if implementation wants to do this or if there is > > ever such use-case. >=20 > I admit I haven't understood the "speak to multiple reflector" part. > How would this work, the reflector is defined by the your_discr of the > outgoing packet, so how can multiple reflectors react on the BFD packet (= ?). > Some kind of multicast or multipoint transport with a "multicast > discriminator"? I wasn't thinking multicast, but fuzzy/vague unicast possibilities. [Mac wrote] > > If a single initiator is to talk to multiple reflectors (a, b, c), > > then my_discrim (x) may be the same for BFD packets sent to (a, b, c). > > When reply from reflectors >=20 > I'd recommend not to allow the same my_discrim for multiple reflectors. > Consider that there are scenarios that multiple S-BFD sessions between th= e > same initiator and reflector, where it requires that the my_discrim shoul= d > be different for different session. Although the same my_discrim for > different reflectiors is techniall workable, this may make the > implementation complex. Agree. Such support shouldn't be a MUST, but I'm just not convinced that we= want to strictly disallow this in the protocol. [Marc wrote] > > IMHO, it may be cleaner to consider defining a packet format > > of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], > > while still using the UDP destination port to demux the packet type. >=20 > Maybe this is the main point: by re-using the D bit it would not be the > RFC5880 packet anymore but a different packet (albeit a small difference)= . > And looking into the Demand parts of 5880 I don't think reusing "Demand" > for S-BFD will fit well. Agree. > One could go back (must go back?) to RFC5880 and declare that the D bit > definition depends on the session type, leave it otherwise undefined in > RFC5880 and re-define today's (D)emand use in RFC5881. And the new use in > the S-BFD document. That would be cleaner, IMHO. But is also a prohibitiv= e > amount of work. S-BFD draft can override the meaning of D-bit in the context of S-BFD only.= We do not need to go back to RFC5880/RFC5881 and make changes. >=20 > (the software change for generic CPU to re-interpret the D bit for S-BFD = is > likely trivial. I like this aspect. Not so sure about your NP though. And= your > ASIC may need a re-spin. It's always the same problem with re-defining > something that is already defined). >=20 > For the introduction of a new version - I got fierce rejection when I pro= posed > it a while ago :-) . We probably would want to introduce more changes th= en, > remember the "want more flags" discussion we had. I remember this very well :) Which is why I'm pushing to avoid that path, until WG consensus shows absol= ute need to do so. -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, March 10, 2014 6:26 PM > To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo) > Cc: Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK > MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello Prasad, Nobo et al., >=20 >=20 > > IMHO, it may be cleaner to consider defining a packet format > > of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], > > while still using the UDP destination port to demux the packet type. >=20 > Maybe this is the main point: by re-using the D bit it would not be the > RFC5880 packet anymore but a different packet (albeit a small difference)= . > And looking into the Demand parts of 5880 I don't think reusing "Demand" > for S-BFD will fit well. > One could go back (must go back?) to RFC5880 and declare that the D bit > definition depends on the session type, leave it otherwise undefined in > RFC5880 and re-define today's (D)emand use in RFC5881. And the new use in > the S-BFD document. That would be cleaner, IMHO. But is also a prohibitiv= e > amount of work. >=20 > (the software change for generic CPU to re-interpret the D bit for S-BFD = is > likely trivial. I like this aspect. Not so sure about your NP though. And= your > ASIC may need a re-spin. It's always the same problem with re-defining > something that is already defined). >=20 > For the introduction of a new version - I got fierce rejection when I pro= posed > it a while ago :-) . We probably would want to introduce more changes th= en, > remember the "want more flags" discussion we had. >=20 >=20 > > [3] Deviating discriminator by reflector session - Proposed will > > prevent a single S-BFD session to speak to multiple reflectors (cannot > > do reply demux'ing), if implementation wants to do this or if there is > > ever such use-case. >=20 > I admit I haven't understood the "speak to multiple reflector" part. > How would this work, the reflector is defined by the your_discr of the > outgoing packet, so how can multiple reflectors react on the BFD packet (= ?). > Some kind of multicast or multipoint transport with a "multicast > discriminator"? >=20 >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govindan (venggovi) > wrote: > > Hello Manav/ all, > > I beg to differ here - while BFD relies on using UDP port numbers to > > demux packet types (Async or Echo), there is currently no notion of > > interpreting bits differently based on UDP destination port numbers. > > IMHO, it may be cleaner to consider defining a packet format of S-BFD > > Async afresh instead of re-defining BFD Async [RFC5880], while still > > using the UDP destination port to demux the packet type. > > This could provide an opportunity to revisit the entire Async header > > to reclaim/ add additional bit(s). Two candidates could be (a) the M > > bit which was intended for P2MP sessions (the Initiator ->Reflector > > model proposed by S-BFD is already MP2P) (b) the > > RequiredMinEchoRxInterval given that S-BFD defines Async only. > > PS> The above two candidates are mere examples to make the case for > > redefining the header and not proposals by themselves. > > Thanks > > Prasad > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, > > Manav (Manav) > > Sent: Monday, March 10, 2014 5:02 AM > > To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA > > (mmudigon); rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Hi Santosh, > > > > Seamless BFD uses a new UDP port and that should be good enough to > > overload the D bit. I don't think we should be revising the version > > number -- at least not based on what I have heard till now. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh > >> P K > >> Sent: Sunday, March 09, 2014 9:18 PM > >> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA > (mmudigon); > >> rtg-bfd@ietf.org > >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> I prefer D-bit option too. Simply because it is clean. D-bit loses > >> its meaning in S-BFD context and I don't think it will be used. Only > >> question is do we need to come up with a new version to use D-bit? > >> > >> Thanks > >> Santosh P K > >> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >> Akiya > >>> (nobo) > >>> Sent: Sunday, March 09, 2014 7:03 PM > >>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > >>> Subject: RE: Loop Prevention in S-BFD > >>> (draft-akiya-bfd-seamless-base) > >>> > >>> Hi Mallik, Greg, [S-]BFDers, > >>> > >>> Please see in-line. > >>> > >>>> -----Original Message----- > >>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >>>> Sent: Saturday, March 08, 2014 4:43 PM > >>>> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- > >> bfd@ietf.org > >>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > >> base) > >>>> > >>>> Dear Mallik, et. al, > >>>> apologies for being terribly behind on processing mail queue. > >>>> I was to propose use of another well-known UDP port for S-BFD but > >> then > >>>> I looked closer at RFC 5881. > >>> > >>> S-BFD proposes to use a new well-known UDP port (starting from base- > >> 02 ... > >>> sorry doc is still not very clear, but we've done major facelift on > >>> - > >> 03, which is to > >>> be submitted after loop/security discussions). And since different > >> UDP ports, > >>> even if were to change meaning of some fields of BFD control header > >> (ex: D bit > >>> interpretation), I don't feel that up versioning is absolutely > >> required. We could, > >>> but we could also avoid. > >>> > >>>> I think that we may use UDP source port of S- BFD packet received > >> by a > >>>> reflector as UDP destination port in reflected packet to break the > >>>> spoofed loop. > >>> > >>> Regarding usage of source UDP port to break the loop, true that's > >> another > >>> possibility. This should definitely be listed as one of the options. > >> It would require > >>> that (dest UDP port !=3D src UDP port) ... and solution is outside of > >> BFD control > >>> header (do we ever want to do IP-less?). > >>> > >>>> If not that, then Option #1 but with new version (I think we'll > >> need > >>>> new version # anyway). > >>> > >>> I'm glad to see that you also prefer option #1. I recommend we move > >> forward > >>> with this, but list all other options in the appendix and keep the > >> discussion open > >>> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, > >>> what > >> do you > >>> think? > >>> > >>> -Nobo > >>> > >>>> > >>>> Regards, > >>>> Greg > >>>> > >>>> -----Original Message----- > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>>> Akiya > >>>> (nobo) > >>>> Sent: Saturday, March 08, 2014 10:46 AM > >>>> To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > >>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > >> base) > >>>> > >>>> Hi Mallik, et al, > >>>> > >>>> My preference: > >>>> > >>>> 1 > 2 > 3 > >>>> > >>>> Reasons: > >>>> > >>>> [3] Deviating discriminator by reflector session - Proposed will > >>>> prevent a single S-BFD session to speak to multiple reflectors > >> (cannot > >>>> do reply demux'ing), if implementation wants to do this or if there > >> is > >>>> ever such use- case. > >>>> > >>>> [2] State - No strong opposition here, but just looks cleaner for > >>>> S-BFD initiator to reflect session state in state field of packets > >> sent. > >>>> > >>>> [1] D bit - I can't think of any reason why S-BFD initiator wants > >> to > >>>> set D bit in packet to reflector session that is stateless. If S- > >> BFD > >>>> initiator is not interested in receiving back any response, S-BFD > >>>> initiator can simply "not send". Thus, there is no issue with > >> changing > >>>> the meaning of D bit in S-BFD context. > >>>> > >>>> -Nobo > >>>> > >>>>> -----Original Message----- > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >> MALLIK > >>>>> MUDIGONDA (mmudigon) > >>>>> Sent: Friday, March 07, 2014 7:58 AM > >>>>> To: rtg-bfd@ietf.org > >>>>> Subject: Loop Prevention in S-BFD > >>>>> (draft-akiya-bfd-seamless-base) > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> Loop prevention > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> Description: > >>>>> > >>>>> Consider a scenario where we have two nodes and both are S-BFD > >> capable. > >>>>> > >>>>> > >>>>> Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > >>>>> | > >>>>> | > >>>>> Man in the Middle (MiM) > >>>>> > >>>>> Node A reserved discriminator 0x01010101 and will have a > >> reflector > >>>>> session in listening mode. Similarly Node B reserved > >> discriminator > >>>>> 0x02020202 for its reflector session. > >>>>> > >>>>> Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, > >>>> YourDisc > >>>>> =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When > >> this > >>>>> packet reaches Node B, the reflector session on Node B will swap > >> the > >>>>> discriminators and IP addresses of the received packet and > >> reflect > >>>>> it back, since YourDisc of the received packet matched with > >> reserved > >>>>> discriminator of Node B. The reflected packet that reached Node A > >>>>> will have > >>>>> MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of t= he > >>>>> received packet matched the reserved discriminator of Node A, > >> Node A > >>>>> will swap the discriminators and reflects the packet back to Node > >> B. > >>>>> Since reflectors MUST set the TTL of the reflected packets to > >> 255, > >>>>> the above scenario will result in an infinite loop with just one > >>>>> malicious packet injected from MiM. > >>>>> > >>>>> FYI: Packet fields do not carry any direction information, i.e., > >> if > >>>>> this is Ping packet or reply packet. > >>>>> > >>>>> Solutions > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> The current proposals are: > >>>>> > >>>>> 1. Overload "D" bit (Demand mode bit). > >>>>> > >>>>> Initiator always sets the 'D' bit and reflector > >> clears it. This > >>>> way > >>>>> we can identify if a received packet was a reflected packet > >>>>> and avoid reflecting it back. However this changes > >> the > >>>>> interpretation of 'D' bit. > >>>>> > >>>>> 2. Use of State field in the BFD control packets: > >>>>> > >>>>> Initiator will always send packets with State set to > >> "DOWN" > >>>>> and reflector will send back packets with state field set to "UP. > >>>>> Reflectors will never reflect any packets with state > >> as "UP". > >>>>> However the only issue is the use of state field differently i.e. > >>>>> state in the S-BFD control packet from initiator does > >> not > >>>>> reflect the local state which is anyway not significant at > >> reflector. > >>>>> > >>>>> 3. Use of local discriminator as My Disc at reflector: > >>>>> > >>>>> Reflector will always fill in My Discriminator with a > >> locally > >>>>> allocated discriminator value (not reserved discriminators) and > >> will > >>>>> not copy it from the received packet. > >>>>> > >>>>> Please share your thoughts on the proposals. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Regards > >>>>> Mallik > >>>>> > >>>>> > >>> > >>> > >> > > From nobody Tue Mar 11 14:10:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BDF1A080A for ; Tue, 11 Mar 2014 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEMusWUVH0k1 for ; Tue, 11 Mar 2014 14:10:40 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2975B1A07FE for ; Tue, 11 Mar 2014 14:10:40 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 688172AA0F; Tue, 11 Mar 2014 21:10:32 +0000 (GMT) Date: Tue, 11 Mar 2014 14:10:32 -0700 From: Marc Binderberger To: Mach Chen Message-ID: <20140311141032394954.6f49449f@sniff.de> In-Reply-To: References: Subject: Re: Question abouth P bit setting MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OSKkNyFEEjM9yzm-n5rbowB8Jhk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 21:10:43 -0000 Hello Mach, > According to the above statement, does it mean that one system of a > BFD session will always send control packet with P bit set when the > BFD session becomes UP from DOWN state ? Because during the DOWN->UP > period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval > will be changed. I would think so, exactly based on the text you quote. What happens if you don't do it? Let's assume your bfd.DesiredMinTxInterval is 1sec for the Down packets, 50msec for Init/Up, bfd.RequiredMinRxInterval is already your fast timer 50msec, for all packets. Changing bfd.DesiredMinTxInterval to a faster interval _and_ sending faster at the same time should not affect the session. Different story when your bfd.RequiredMinRxInterval also starts as 1sec. Adjusting the timeout timer based on a new, smaller bfd.RequiredMinRxInterval should only happen when the peer has acknowledged it is sending faster. Exactly what the Poll sequence is for. So in short: it may work, depending on the details above. But clearly expect other systems to use the Poll sequence, i.e. you must be able to support receiving the Poll sequence even at that early stage of the session. My $0.02 Regards, Marc > Section 6.8.3. Timer Manipulation (RFC5880), second paragraph states: > > "If either bfd.DesiredMinTxInterval is changed or > bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be > initiated (see section 6.5). If the timing is such that a system > receiving a Poll Sequence wishes to change the parameters described > in this paragraph, the new parameter values MAY be carried in packets > with the Final (F) bit set, even if the Poll Sequence has not yet > been sent." > > According to the above statement, does it mean that one system of a > BFD session will always send control packet with P bit set when the > BFD session becomes UP from DOWN state ? Because during the DOWN->UP > period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval > will be changed. > > Thanks, > Mach > From nobody Tue Mar 11 16:57:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB031A088F for ; Tue, 11 Mar 2014 16:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEU25OZC_DCA for ; Tue, 11 Mar 2014 16:57:14 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E888A1A0884 for ; Tue, 11 Mar 2014 16:57:13 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 35BEF2AA0F; Tue, 11 Mar 2014 23:57:04 +0000 (GMT) Date: Tue, 11 Mar 2014 16:57:05 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140311165705373444.759ede3c@sniff.de> In-Reply-To: References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0B_jOXaYDgyyyKL-bW5tAQnJK5M Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 23:57:18 -0000 Hello Nobo et al., > S-BFD draft can override the meaning of D-bit in the context of S-BFD > only. We do not need to go back to RFC5880/RFC5881 and make changes. This is an interesting point: can we? Technically I like to have a flag to separate the "ping" from the "pong". Simple logic. Redefining a packet definition, not "from here on" but in parallel to the still valid RFC5880 seems somewhat odd to me. Do we have examples in IETF for this? Regards, Marc On Tue, 11 Mar 2014 14:27:41 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, Mach, > > Thanks for comments! > > Combining the responses into a single thread. > > [Marc wrote] >>> [3] Deviating discriminator by reflector session - Proposed will >>> prevent a single S-BFD session to speak to multiple reflectors (cannot >>> do reply demux'ing), if implementation wants to do this or if there is >>> ever such use-case. >> >> I admit I haven't understood the "speak to multiple reflector" part. >> How would this work, the reflector is defined by the your_discr of the >> outgoing packet, so how can multiple reflectors react on the BFD >> packet (?). >> Some kind of multicast or multipoint transport with a "multicast >> discriminator"? > > I wasn't thinking multicast, but fuzzy/vague unicast possibilities. > > [Mac wrote] >>> If a single initiator is to talk to multiple reflectors (a, b, c), >>> then my_discrim (x) may be the same for BFD packets sent to (a, b, c). >>> When reply from reflectors >> >> I'd recommend not to allow the same my_discrim for multiple reflectors. >> Consider that there are scenarios that multiple S-BFD sessions between the >> same initiator and reflector, where it requires that the my_discrim should >> be different for different session. Although the same my_discrim for >> different reflectiors is techniall workable, this may make the >> implementation complex. > > Agree. Such support shouldn't be a MUST, but I'm just not convinced > that we want to strictly disallow this in the protocol. > > [Marc wrote] >>> IMHO, it may be cleaner to consider defining a packet format >>> of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], >>> while still using the UDP destination port to demux the packet type. >> >> Maybe this is the main point: by re-using the D bit it would not be the >> RFC5880 packet anymore but a different packet (albeit a small difference). >> And looking into the Demand parts of 5880 I don't think reusing "Demand" >> for S-BFD will fit well. > > Agree. > >> One could go back (must go back?) to RFC5880 and declare that the D bit >> definition depends on the session type, leave it otherwise undefined in >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new use in >> the S-BFD document. That would be cleaner, IMHO. But is also a prohibitive >> amount of work. > > S-BFD draft can override the meaning of D-bit in the context of S-BFD > only. We do not need to go back to RFC5880/RFC5881 and make changes. > >> >> (the software change for generic CPU to re-interpret the D bit for S-BFD is >> likely trivial. I like this aspect. Not so sure about your NP >> though. And your >> ASIC may need a re-spin. It's always the same problem with re-defining >> something that is already defined). >> >> For the introduction of a new version - I got fierce rejection when >> I proposed >> it a while ago :-) . We probably would want to introduce more >> changes then, >> remember the "want more flags" discussion we had. > > I remember this very well :) > > Which is why I'm pushing to avoid that path, until WG consensus shows > absolute need to do so. > > -Nobo > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, March 10, 2014 6:26 PM >> To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo) >> Cc: Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK >> MUDIGONDA (mmudigon); rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hello Prasad, Nobo et al., >> >> >>> IMHO, it may be cleaner to consider defining a packet format >>> of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], >>> while still using the UDP destination port to demux the packet type. >> >> Maybe this is the main point: by re-using the D bit it would not be the >> RFC5880 packet anymore but a different packet (albeit a small difference). >> And looking into the Demand parts of 5880 I don't think reusing "Demand" >> for S-BFD will fit well. >> One could go back (must go back?) to RFC5880 and declare that the D bit >> definition depends on the session type, leave it otherwise undefined in >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new use in >> the S-BFD document. That would be cleaner, IMHO. But is also a prohibitive >> amount of work. >> >> (the software change for generic CPU to re-interpret the D bit for S-BFD is >> likely trivial. I like this aspect. Not so sure about your NP >> though. And your >> ASIC may need a re-spin. It's always the same problem with re-defining >> something that is already defined). >> >> For the introduction of a new version - I got fierce rejection when >> I proposed >> it a while ago :-) . We probably would want to introduce more >> changes then, >> remember the "want more flags" discussion we had. >> >> >>> [3] Deviating discriminator by reflector session - Proposed will >>> prevent a single S-BFD session to speak to multiple reflectors (cannot >>> do reply demux'ing), if implementation wants to do this or if there is >>> ever such use-case. >> >> I admit I haven't understood the "speak to multiple reflector" part. >> How would this work, the reflector is defined by the your_discr of the >> outgoing packet, so how can multiple reflectors react on the BFD >> packet (?). >> Some kind of multicast or multipoint transport with a "multicast >> discriminator"? >> >> >> >> Regards, Marc >> >> >> >> >> On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govindan (venggovi) >> wrote: >>> Hello Manav/ all, >>> I beg to differ here - while BFD relies on using UDP port numbers to >>> demux packet types (Async or Echo), there is currently no notion of >>> interpreting bits differently based on UDP destination port numbers. >>> IMHO, it may be cleaner to consider defining a packet format of S-BFD >>> Async afresh instead of re-defining BFD Async [RFC5880], while still >>> using the UDP destination port to demux the packet type. >>> This could provide an opportunity to revisit the entire Async header >>> to reclaim/ add additional bit(s). Two candidates could be (a) the M >>> bit which was intended for P2MP sessions (the Initiator ->Reflector >>> model proposed by S-BFD is already MP2P) (b) the >>> RequiredMinEchoRxInterval given that S-BFD defines Async only. >>> PS> The above two candidates are mere examples to make the case for >>> redefining the header and not proposals by themselves. >>> Thanks >>> Prasad >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, >>> Manav (Manav) >>> Sent: Monday, March 10, 2014 5:02 AM >>> To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA >>> (mmudigon); rtg-bfd@ietf.org >>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>> >>> Hi Santosh, >>> >>> Seamless BFD uses a new UDP port and that should be good enough to >>> overload the D bit. I don't think we should be revising the version >>> number -- at least not based on what I have heard till now. >>> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh >>>> P K >>>> Sent: Sunday, March 09, 2014 9:18 PM >>>> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA >> (mmudigon); >>>> rtg-bfd@ietf.org >>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>> >>>> I prefer D-bit option too. Simply because it is clean. D-bit loses >>>> its meaning in S-BFD context and I don't think it will be used. Only >>>> question is do we need to come up with a new version to use D-bit? >>>> >>>> Thanks >>>> Santosh P K >>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>> Akiya >>>>> (nobo) >>>>> Sent: Sunday, March 09, 2014 7:03 PM >>>>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org >>>>> Subject: RE: Loop Prevention in S-BFD >>>>> (draft-akiya-bfd-seamless-base) >>>>> >>>>> Hi Mallik, Greg, [S-]BFDers, >>>>> >>>>> Please see in-line. >>>>> >>>>>> -----Original Message----- >>>>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>>>>> Sent: Saturday, March 08, 2014 4:43 PM >>>>>> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- >>>> bfd@ietf.org >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >>>> base) >>>>>> >>>>>> Dear Mallik, et. al, >>>>>> apologies for being terribly behind on processing mail queue. >>>>>> I was to propose use of another well-known UDP port for S-BFD but >>>> then >>>>>> I looked closer at RFC 5881. >>>>> >>>>> S-BFD proposes to use a new well-known UDP port (starting from base- >>>> 02 ... >>>>> sorry doc is still not very clear, but we've done major facelift on >>>>> - >>>> 03, which is to >>>>> be submitted after loop/security discussions). And since different >>>> UDP ports, >>>>> even if were to change meaning of some fields of BFD control header >>>> (ex: D bit >>>>> interpretation), I don't feel that up versioning is absolutely >>>> required. We could, >>>>> but we could also avoid. >>>>> >>>>>> I think that we may use UDP source port of S- BFD packet received >>>> by a >>>>>> reflector as UDP destination port in reflected packet to break the >>>>>> spoofed loop. >>>>> >>>>> Regarding usage of source UDP port to break the loop, true that's >>>> another >>>>> possibility. This should definitely be listed as one of the options. >>>> It would require >>>>> that (dest UDP port != src UDP port) ... and solution is outside of >>>> BFD control >>>>> header (do we ever want to do IP-less?). >>>>> >>>>>> If not that, then Option #1 but with new version (I think we'll >>>> need >>>>>> new version # anyway). >>>>> >>>>> I'm glad to see that you also prefer option #1. I recommend we move >>>> forward >>>>> with this, but list all other options in the appendix and keep the >>>> discussion open >>>>> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, >>>>> what >>>> do you >>>>> think? >>>>> >>>>> -Nobo >>>>> >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>>>> Akiya >>>>>> (nobo) >>>>>> Sent: Saturday, March 08, 2014 10:46 AM >>>>>> To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >>>> base) >>>>>> >>>>>> Hi Mallik, et al, >>>>>> >>>>>> My preference: >>>>>> >>>>>> 1 > 2 > 3 >>>>>> >>>>>> Reasons: >>>>>> >>>>>> [3] Deviating discriminator by reflector session - Proposed will >>>>>> prevent a single S-BFD session to speak to multiple reflectors >>>> (cannot >>>>>> do reply demux'ing), if implementation wants to do this or if there >>>> is >>>>>> ever such use- case. >>>>>> >>>>>> [2] State - No strong opposition here, but just looks cleaner for >>>>>> S-BFD initiator to reflect session state in state field of packets >>>> sent. >>>>>> >>>>>> [1] D bit - I can't think of any reason why S-BFD initiator wants >>>> to >>>>>> set D bit in packet to reflector session that is stateless. If S- >>>> BFD >>>>>> initiator is not interested in receiving back any response, S-BFD >>>>>> initiator can simply "not send". Thus, there is no issue with >>>> changing >>>>>> the meaning of D bit in S-BFD context. >>>>>> >>>>>> -Nobo >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>> MALLIK >>>>>>> MUDIGONDA (mmudigon) >>>>>>> Sent: Friday, March 07, 2014 7:58 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Loop Prevention in S-BFD >>>>>>> (draft-akiya-bfd-seamless-base) >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Loop prevention >>>>>>> =============== >>>>>>> >>>>>>> Description: >>>>>>> >>>>>>> Consider a scenario where we have two nodes and both are S-BFD >>>> capable. >>>>>>> >>>>>>> >>>>>>> Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) >>>>>>> | >>>>>>> | >>>>>>> Man in the Middle (MiM) >>>>>>> >>>>>>> Node A reserved discriminator 0x01010101 and will have a >>>> reflector >>>>>>> session in listening mode. Similarly Node B reserved >>>> discriminator >>>>>>> 0x02020202 for its reflector session. >>>>>>> >>>>>>> Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, >>>>>> YourDisc >>>>>>> = 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When >>>> this >>>>>>> packet reaches Node B, the reflector session on Node B will swap >>>> the >>>>>>> discriminators and IP addresses of the received packet and >>>> reflect >>>>>>> it back, since YourDisc of the received packet matched with >>>> reserved >>>>>>> discriminator of Node B. The reflected packet that reached Node A >>>>>>> will have >>>>>>> MyDdisc=0x02020202 and YourDisc=0x01010101. Since YourDisc of the >>>>>>> received packet matched the reserved discriminator of Node A, >>>> Node A >>>>>>> will swap the discriminators and reflects the packet back to Node >>>> B. >>>>>>> Since reflectors MUST set the TTL of the reflected packets to >>>> 255, >>>>>>> the above scenario will result in an infinite loop with just one >>>>>>> malicious packet injected from MiM. >>>>>>> >>>>>>> FYI: Packet fields do not carry any direction information, i.e., >>>> if >>>>>>> this is Ping packet or reply packet. >>>>>>> >>>>>>> Solutions >>>>>>> ========= >>>>>>> >>>>>>> The current proposals are: >>>>>>> >>>>>>> 1. Overload "D" bit (Demand mode bit). >>>>>>> >>>>>>> Initiator always sets the 'D' bit and reflector >>>> clears it. This >>>>>> way >>>>>>> we can identify if a received packet was a reflected packet >>>>>>> and avoid reflecting it back. However this changes >>>> the >>>>>>> interpretation of 'D' bit. >>>>>>> >>>>>>> 2. Use of State field in the BFD control packets: >>>>>>> >>>>>>> Initiator will always send packets with State set to >>>> "DOWN" >>>>>>> and reflector will send back packets with state field set to "UP. >>>>>>> Reflectors will never reflect any packets with state >>>> as "UP". >>>>>>> However the only issue is the use of state field differently i.e. >>>>>>> state in the S-BFD control packet from initiator does >>>> not >>>>>>> reflect the local state which is anyway not significant at >>>> reflector. >>>>>>> >>>>>>> 3. Use of local discriminator as My Disc at reflector: >>>>>>> >>>>>>> Reflector will always fill in My Discriminator with a >>>> locally >>>>>>> allocated discriminator value (not reserved discriminators) and >>>> will >>>>>>> not copy it from the received packet. >>>>>>> >>>>>>> Please share your thoughts on the proposals. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Regards >>>>>>> Mallik >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> > From nobody Tue Mar 11 23:26:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369CD1A08EB for ; Tue, 11 Mar 2014 23:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5UKxbVL_9xt for ; Tue, 11 Mar 2014 23:26:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8371A08E8 for ; Tue, 11 Mar 2014 23:26:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEM14068; Wed, 12 Mar 2014 06:26:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 06:25:39 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 06:26:26 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 12 Mar 2014 14:26:20 +0800 From: Mach Chen To: Binny Jeshan Subject: RE: Question abouth P bit setting Thread-Topic: Question abouth P bit setting Thread-Index: Ac88/5dFi5viacsrTWOzMz5Bed6N9P//nJeA//55C1A= Date: Wed, 12 Mar 2014 06:26:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D98974FSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Qq_L7E7AlHwMvjeQceVegYh-8Tw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 06:26:46 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D98974FSZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Binny, Thanks for the detail explanation, it's clear. According to your and Marc's response, seems that one system could choose t= o set the P bit (strictly as RFC5880 says) or clear the P bit (as you said = and some implementations do). The key point is that the remote system could= properly process the control packet with/without P bit set. Ask this question, because I saw two implementations that one set the P bit= and the other does not. Best regards, Mach From: Binny Jeshan [mailto:binnyjeshan@gmail.com] Sent: Tuesday, March 11, 2014 6:02 PM To: Mach Chen Cc: rtg-bfd@ietf.org Subject: Re: Question abouth P bit setting Hi Mach, During this phase the P Bit must not be set. P Bit has to be set only whe= n the Timers are Changed from the Configuration "After the First negotiatio= n was already done and the session was continuing to work". P Bit is as sim= ple as to tell the peer to either 1) Enter the Re-negotiate phase again 2) = Observe parameter changes (may be auth / other etc)... In your case, the session when it goes DOWN, it Moves its timers to a "Slow= Interval" which is a standard >=3D 1 second value. This is known to the pe= er that in a DOWN session state the remote would operate in Slower interval= and the peer system need not worry on what exact timer its using because i= n DOWN state the Peer is not going to observe for any defects, but just wai= t for the next UP packet only. Is this clear now? Please let us know if any further questions. Regards, Binny. On 11 March 2014 09:57, Mach Chen > wrote: Hi BFDers, Section 6.8.3. Timer Manipulation (RFC5880), second paragraph states: "If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated (see section 6.5). If the timing is such that a system receiving a Poll Sequence wishes to change the parameters described in this paragraph, the new parameter values MAY be carried in packets with the Final (F) bit set, even if the Poll Sequence has not yet been sent." According to the above statement, does it mean that one system of a BFD ses= sion will always send control packet with P bit set when the BFD session be= comes UP from DOWN state ? Because during the DOWN->UP period, the bfd.Desi= redMinTxInterval and bfd.RequiredMinRxInterval will be changed. Thanks, Mach --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D98974FSZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Binny,

=  

= Thanks for the detail explanation= , it’s clear.

=  

= According to your and Marc’= s response, seems that one system could choose to set the P bit (strictly as RFC5880 s= ays) or clear the P bit (as you said and some implementations do). The key = point is that the remote system could properly process the control packet w= ith/without P bit set.

=  

= Ask this question, because I saw two implementations that one set the P bit and the other does not.  

=  

= Best regards,

= Mach

=  

From: Binny Jeshan [mailto:binnyjeshan@gmail.com]
Sent: Tuesday, March 11, 201= 4 6:02 PM
To: Mach Chen
Cc: rtg-bfd@ietf.org
Subject: Re: Question abouth= P bit setting

 

Hi Mach,

 

During this phase the P Bit &nbs= p; must not be set. P Bit has to be set only when the Timers are Changed fr= om the Configuration "After the First negotiation was already done and the session was continuing to work". P Bit is as sim= ple as to tell the peer to either 1) Enter the Re-negotiate phase agai= n 2) Observe parameter changes (may be auth / other etc)...  

 

In your case, the session when it goe= s DOWN, it Moves its timers to a "Slow Interval" which is a stand= ard >=3D 1 second value. This is known to the peer that in a DOWN session state the remote would operate in Slower interval and th= e peer system need not worry on what exact timer its using because in = DOWN state the Peer is not going to observe for any defects, but just wait = for the next UP packet only.

 

Is this clear now? Please let us know= if any further questions.

 

Regards,

Binny.

&= nbsp;

On 11 March 2014 09:57, Mach Chen <= ;mach.chen@huawei= .com> wrote:

Hi BFD= ers,


Section 6.8.3.  Timer Manipulation (RFC5880), second paragraph states:=

"If either bfd.DesiredMinTxInterval is changed or
   bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be<= br>    initiated (see section 6.5).  If the timing is such that = a system
   receiving a Poll Sequence wishes to change the parameters desc= ribed
   in this paragraph, the new parameter values MAY be carried in = packets
   with the Final (F) bit set, even if the Poll Sequence has not = yet
   been sent."

According to the above statement, does it mean that one system of a BFD ses= sion will always send control packet with P bit set when the BFD session be= comes UP from DOWN state ? Because during the DOWN->UP period, the bfd.D= esiredMinTxInterval and   bfd.RequiredMinRxInterval will be changed.

Thanks,
Mach

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D98974FSZXEMA510MBXchi_-- From nobody Tue Mar 11 23:34:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7531A08EA for ; Tue, 11 Mar 2014 23:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpQ_0ZkHd-qj for ; Tue, 11 Mar 2014 23:34:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2131A08E8 for ; Tue, 11 Mar 2014 23:34:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEM14695; Wed, 12 Mar 2014 06:34:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 06:33:42 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 06:34:33 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 12 Mar 2014 14:34:26 +0800 From: Mach Chen To: Marc Binderberger Subject: RE: Question abouth P bit setting Thread-Topic: Question abouth P bit setting Thread-Index: Ac88/5dFi5viacsrTWOzMz5Bed6N9AAK7DYAACQtbUA= Date: Wed, 12 Mar 2014 06:34:26 +0000 Message-ID: References: <20140311141032394954.6f49449f@sniff.de> In-Reply-To: <20140311141032394954.6f49449f@sniff.de> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/F6mm5-uEt783vcCjW5306RQn8PA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 06:34:51 -0000 Hi Marc, Thanks for your prompt reply. See my response inline... > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Wednesday, March 12, 2014 5:11 AM > To: Mach Chen > Cc: rtg-bfd@ietf.org > Subject: Re: Question abouth P bit setting >=20 > Hello Mach, >=20 > > According to the above statement, does it mean that one system of a > > BFD session will always send control packet with P bit set when the > > BFD session becomes UP from DOWN state ? Because during the DOWN->UP > > period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval > > will be changed. >=20 > I would think so, exactly based on the text you quote. >=20 > What happens if you don't do it? Let's assume your bfd.DesiredMinTxInter= val is I think most of the implementations can handle the control packets with P b= it set. I saw one implementation that expects to receive the control packet with P = bit set during the initial phase, this may result in failing to establish t= he BFD session.=20 > 1sec for the Down packets, 50msec for Init/Up, bfd.RequiredMinRxInterval = is > already your fast timer 50msec, for all packets. Changing > bfd.DesiredMinTxInterval to a faster interval _and_ sending faster at the= same > time should not affect the session. >=20 > Different story when your bfd.RequiredMinRxInterval also starts as 1sec. > Adjusting the timeout timer based on a new, smaller bfd.RequiredMinRxInte= rval > should only happen when the peer has acknowledged it is sending faster. E= xactly > what the Poll sequence is for. >=20 >=20 > So in short: it may work, depending on the details above. But clearly exp= ect other > systems to use the Poll sequence, i.e. you must be able to support receiv= ing the > Poll sequence even at that early stage of the session. Yes, agree. Thanks, Mach >=20 >=20 > My $0.02 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > > Section 6.8.3. Timer Manipulation (RFC5880), second paragraph states: > > > > "If either bfd.DesiredMinTxInterval is changed or > > bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be > > initiated (see section 6.5). If the timing is such that a system > > receiving a Poll Sequence wishes to change the parameters described > > in this paragraph, the new parameter values MAY be carried in packet= s > > with the Final (F) bit set, even if the Poll Sequence has not yet > > been sent." > > > > According to the above statement, does it mean that one system of a > > BFD session will always send control packet with P bit set when the > > BFD session becomes UP from DOWN state ? Because during the DOWN->UP > > period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval > > will be changed. > > > > Thanks, > > Mach > > From nobody Wed Mar 12 00:07:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBC91A03BD for ; Wed, 12 Mar 2014 00:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tID6A6M8XCD for ; Wed, 12 Mar 2014 00:07:26 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D16C81A04B7 for ; Wed, 12 Mar 2014 00:07:25 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3C3772AA0F; Wed, 12 Mar 2014 07:07:17 +0000 (GMT) Date: Wed, 12 Mar 2014 00:07:19 -0700 From: Marc Binderberger To: Mach Chen Message-ID: <20140312000719340717.296a6099@sniff.de> In-Reply-To: References: <20140311141032394954.6f49449f@sniff.de> Subject: RE: Question abouth P bit setting MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nWG1xGbz2uKEiovqRc4sOOvYEdw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 07:07:28 -0000 Hello Mach, > I saw one implementation that expects to receive the control packet > with P bit set during the initial phase, this may result in failing > to establish the BFD session. "Be liberal in what you accept, and conservative in what you send" RFC122, section 1.2.2 :-) Regards, Marc P.S.: now don't tell me it was an implementation I was working on ... :-) On Wed, 12 Mar 2014 06:34:26 +0000, Mach Chen wrote: > Hi Marc, > > Thanks for your prompt reply. > > See my response inline... > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> Binderberger >> Sent: Wednesday, March 12, 2014 5:11 AM >> To: Mach Chen >> Cc: rtg-bfd@ietf.org >> Subject: Re: Question abouth P bit setting >> >> Hello Mach, >> >>> According to the above statement, does it mean that one system of a >>> BFD session will always send control packet with P bit set when the >>> BFD session becomes UP from DOWN state ? Because during the DOWN->UP >>> period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval >>> will be changed. >> >> I would think so, exactly based on the text you quote. >> >> What happens if you don't do it? Let's assume your >> bfd.DesiredMinTxInterval is > > I think most of the implementations can handle the control packets > with P bit set. > > I saw one implementation that expects to receive the control packet > with P bit set during the initial phase, this may result in failing > to establish the BFD session. > >> 1sec for the Down packets, 50msec for Init/Up, bfd.RequiredMinRxInterval is >> already your fast timer 50msec, for all packets. Changing >> bfd.DesiredMinTxInterval to a faster interval _and_ sending faster >> at the same >> time should not affect the session. >> >> Different story when your bfd.RequiredMinRxInterval also starts as 1sec. >> Adjusting the timeout timer based on a new, smaller >> bfd.RequiredMinRxInterval >> should only happen when the peer has acknowledged it is sending >> faster. Exactly >> what the Poll sequence is for. >> >> >> So in short: it may work, depending on the details above. But >> clearly expect other >> systems to use the Poll sequence, i.e. you must be able to support >> receiving the >> Poll sequence even at that early stage of the session. > > Yes, agree. > > Thanks, > Mach > >> >> >> My $0.02 >> >> Regards, Marc >> >> >> >> >>> Section 6.8.3. Timer Manipulation (RFC5880), second paragraph states: >>> >>> "If either bfd.DesiredMinTxInterval is changed or >>> bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be >>> initiated (see section 6.5). If the timing is such that a system >>> receiving a Poll Sequence wishes to change the parameters described >>> in this paragraph, the new parameter values MAY be carried in packets >>> with the Final (F) bit set, even if the Poll Sequence has not yet >>> been sent." >>> >>> According to the above statement, does it mean that one system of a >>> BFD session will always send control packet with P bit set when the >>> BFD session becomes UP from DOWN state ? Because during the DOWN->UP >>> period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval >>> will be changed. >>> >>> Thanks, >>> Mach >>> > From nobody Wed Mar 12 00:48:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1D51A0901 for ; Wed, 12 Mar 2014 00:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkp9gi6E-wsB for ; Wed, 12 Mar 2014 00:47:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E29521A08EB for ; Wed, 12 Mar 2014 00:47:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBZ32853; Wed, 12 Mar 2014 07:47:51 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 07:46:48 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 07:47:38 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 12 Mar 2014 15:47:33 +0800 From: Mach Chen To: Marc Binderberger Subject: RE: Question abouth P bit setting Thread-Topic: Question abouth P bit setting Thread-Index: Ac88/5dFi5viacsrTWOzMz5Bed6N9AAK7DYAACQtbUD//4VRgP//cUWg Date: Wed, 12 Mar 2014 07:47:33 +0000 Message-ID: References: <20140311141032394954.6f49449f@sniff.de> <20140312000719340717.296a6099@sniff.de> In-Reply-To: <20140312000719340717.296a6099@sniff.de> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/rA3cFGrvwn4xgpxKSyAiB-n-PTQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 07:48:01 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Wednesday, March 12, 2014 3:07 PM > To: Mach Chen > Cc: rtg-bfd@ietf.org > Subject: RE: Question abouth P bit setting >=20 > Hello Mach, >=20 > > I saw one implementation that expects to receive the control packet > > with P bit set during the initial phase, this may result in failing to > > establish the BFD session. >=20 > "Be liberal in what you accept, and > conservative in what you send" >=20 > RFC122, section 1.2.2 :-) Yes, good point! >=20 >=20 > Regards, Marc >=20 > P.S.: now don't tell me it was an implementation I was working on ... > :-) Let's guess :-) Best regards, Mach >=20 >=20 >=20 > On Wed, 12 Mar 2014 06:34:26 +0000, Mach Chen wrote: > > Hi Marc, > > > > Thanks for your prompt reply. > > > > See my response inline... > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > >> Binderberger > >> Sent: Wednesday, March 12, 2014 5:11 AM > >> To: Mach Chen > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: Question abouth P bit setting > >> > >> Hello Mach, > >> > >>> According to the above statement, does it mean that one system of a > >>> BFD session will always send control packet with P bit set when the > >>> BFD session becomes UP from DOWN state ? Because during the > DOWN->UP > >>> period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval > >>> will be changed. > >> > >> I would think so, exactly based on the text you quote. > >> > >> What happens if you don't do it? Let's assume your > >> bfd.DesiredMinTxInterval is > > > > I think most of the implementations can handle the control packets > > with P bit set. > > > > I saw one implementation that expects to receive the control packet > > with P bit set during the initial phase, this may result in failing to > > establish the BFD session. > > > >> 1sec for the Down packets, 50msec for Init/Up, > >> bfd.RequiredMinRxInterval is already your fast timer 50msec, for all > >> packets. Changing bfd.DesiredMinTxInterval to a faster interval _and_ > >> sending faster at the same time should not affect the session. > >> > >> Different story when your bfd.RequiredMinRxInterval also starts as 1se= c. > >> Adjusting the timeout timer based on a new, smaller > >> bfd.RequiredMinRxInterval should only happen when the peer has > >> acknowledged it is sending faster. Exactly what the Poll sequence is > >> for. > >> > >> > >> So in short: it may work, depending on the details above. But clearly > >> expect other systems to use the Poll sequence, i.e. you must be able > >> to support receiving the Poll sequence even at that early stage of > >> the session. > > > > Yes, agree. > > > > Thanks, > > Mach > > > >> > >> > >> My $0.02 > >> > >> Regards, Marc > >> > >> > >> > >> > >>> Section 6.8.3. Timer Manipulation (RFC5880), second paragraph states= : > >>> > >>> "If either bfd.DesiredMinTxInterval is changed or > >>> bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be > >>> initiated (see section 6.5). If the timing is such that a system > >>> receiving a Poll Sequence wishes to change the parameters describe= d > >>> in this paragraph, the new parameter values MAY be carried in pack= ets > >>> with the Final (F) bit set, even if the Poll Sequence has not yet > >>> been sent." > >>> > >>> According to the above statement, does it mean that one system of a > >>> BFD session will always send control packet with P bit set when the > >>> BFD session becomes UP from DOWN state ? Because during the > DOWN->UP > >>> period, the bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval > >>> will be changed. > >>> > >>> Thanks, > >>> Mach > >>> > > From nobody Wed Mar 12 05:36:25 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63C1A0968 for ; Wed, 12 Mar 2014 05:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7CHi5Isztqc for ; Wed, 12 Mar 2014 05:36:19 -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 1998A1A0958 for ; Wed, 12 Mar 2014 05:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17287; q=dns/txt; s=iport; t=1394627773; x=1395837373; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+ZQIHQ7IOIW80OJBGebvHzD1eZ9z9qc8rYF1g6MYJT0=; b=GiYEVqC+c0SdJvMdU3/hXZByhMovG/rdGA0vQZplrF5KUdcCuICu/rD2 534fzMTNuaVfJJyJc3wNqavTDUHeTjqKPCpzAInb2GOULA3f8nu6HJ15E kqJJ9jl4Pzpq37QqzvkC7E8OYZxE/9VZMfm1o17+HPY+tEFyNVgGNsaIU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAPVTIFOtJXHA/2dsb2JhbABQCoJlIYESvV6Dc4EbFnSCJQEBAQMBJxM/DAQCAQgRBAEBAQoUCQcyFAkIAgQOBQgTh1YIAdFuF44ACwEBHjEHBoMegRQBA6pygy2BaQYDFyI X-IronPort-AV: E=Sophos;i="4.97,637,1389744000"; d="scan'208";a="309758263" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 12 Mar 2014 12:36:12 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2CCaBFT011133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 12:36:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 07:36:11 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgAB/pvA= Date: Wed, 12 Mar 2014 12:36:11 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> In-Reply-To: <20140311165705373444.759ede3c@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/e-_-bsoorL2YfjfvtrB1dX8DRHw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 12:36:22 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, March 11, 2014 7:57 PM > To: Nobo Akiya (nobo) > Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P > K; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello Nobo et al., >=20 >=20 > > S-BFD draft can override the meaning of D-bit in the context of S-BFD > > only. We do not need to go back to RFC5880/RFC5881 and make changes. >=20 > This is an interesting point: can we? Yes, S-BFD base document can update RFC5880 wrt D bit definition and proced= ures. i.e. For S-BFD, meaning and procedure is foobar. For all other BFD types, r= emains as defined in RFC5880. -Nobo >=20 > Technically I like to have a flag to separate the "ping" from the "pong". > Simple logic. Redefining a packet definition, not "from here on" but in > parallel to the still valid RFC5880 seems somewhat odd to me. Do we have > examples in IETF for this? >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Tue, 11 Mar 2014 14:27:41 +0000, Nobo Akiya (nobo) wrote: > > Hi Marc, Mach, > > > > Thanks for comments! > > > > Combining the responses into a single thread. > > > > [Marc wrote] > >>> [3] Deviating discriminator by reflector session - Proposed will > >>> prevent a single S-BFD session to speak to multiple reflectors > >>> (cannot do reply demux'ing), if implementation wants to do this or > >>> if there is ever such use-case. > >> > >> I admit I haven't understood the "speak to multiple reflector" part. > >> How would this work, the reflector is defined by the your_discr of > >> the outgoing packet, so how can multiple reflectors react on the BFD > >> packet (?). > >> Some kind of multicast or multipoint transport with a "multicast > >> discriminator"? > > > > I wasn't thinking multicast, but fuzzy/vague unicast possibilities. > > > > [Mac wrote] > >>> If a single initiator is to talk to multiple reflectors (a, b, c), > >>> then my_discrim (x) may be the same for BFD packets sent to (a, b, c)= . > >>> When reply from reflectors > >> > >> I'd recommend not to allow the same my_discrim for multiple reflectors= . > >> Consider that there are scenarios that multiple S-BFD sessions > >> between the same initiator and reflector, where it requires that the > >> my_discrim should be different for different session. Although the > >> same my_discrim for different reflectiors is techniall workable, this > >> may make the implementation complex. > > > > Agree. Such support shouldn't be a MUST, but I'm just not convinced > > that we want to strictly disallow this in the protocol. > > > > [Marc wrote] > >>> IMHO, it may be cleaner to consider defining a packet > >>> format of S-BFD Async afresh instead of re-defining BFD Async > >>> [RFC5880], while still using the UDP destination port to demux the > packet type. > >> > >> Maybe this is the main point: by re-using the D bit it would not be > >> the > >> RFC5880 packet anymore but a different packet (albeit a small differen= ce). > >> And looking into the Demand parts of 5880 I don't think reusing > "Demand" > >> for S-BFD will fit well. > > > > Agree. > > > >> One could go back (must go back?) to RFC5880 and declare that the D > >> bit definition depends on the session type, leave it otherwise > >> undefined in > >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new > >> use in the S-BFD document. That would be cleaner, IMHO. But is also a > >> prohibitive amount of work. > > > > S-BFD draft can override the meaning of D-bit in the context of S-BFD > > only. We do not need to go back to RFC5880/RFC5881 and make changes. > > > >> > >> (the software change for generic CPU to re-interpret the D bit for > >> S-BFD is likely trivial. I like this aspect. Not so sure about your > >> NP though. And your ASIC may need a re-spin. It's always the same > >> problem with re-defining something that is already defined). > >> > >> For the introduction of a new version - I got fierce rejection when I > >> proposed it a while ago :-) . We probably would want to introduce > >> more changes then, remember the "want more flags" discussion we had. > > > > I remember this very well :) > > > > Which is why I'm pushing to avoid that path, until WG consensus shows > > absolute need to do so. > > > > -Nobo > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Monday, March 10, 2014 6:26 PM > >> To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo) > >> Cc: Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK > >> MUDIGONDA (mmudigon); rtg-bfd@ietf.org > >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> Hello Prasad, Nobo et al., > >> > >> > >>> IMHO, it may be cleaner to consider defining a packet > >>> format of S-BFD Async afresh instead of re-defining BFD Async > >>> [RFC5880], while still using the UDP destination port to demux the > packet type. > >> > >> Maybe this is the main point: by re-using the D bit it would not be > >> the > >> RFC5880 packet anymore but a different packet (albeit a small differen= ce). > >> And looking into the Demand parts of 5880 I don't think reusing > "Demand" > >> for S-BFD will fit well. > >> One could go back (must go back?) to RFC5880 and declare that the D > >> bit definition depends on the session type, leave it otherwise > >> undefined in > >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new > >> use in the S-BFD document. That would be cleaner, IMHO. But is also a > >> prohibitive amount of work. > >> > >> (the software change for generic CPU to re-interpret the D bit for > >> S-BFD is likely trivial. I like this aspect. Not so sure about your > >> NP though. And your ASIC may need a re-spin. It's always the same > >> problem with re-defining something that is already defined). > >> > >> For the introduction of a new version - I got fierce rejection when I > >> proposed it a while ago :-) . We probably would want to introduce > >> more changes then, remember the "want more flags" discussion we had. > >> > >> > >>> [3] Deviating discriminator by reflector session - Proposed will > >>> prevent a single S-BFD session to speak to multiple reflectors > >>> (cannot do reply demux'ing), if implementation wants to do this or > >>> if there is ever such use-case. > >> > >> I admit I haven't understood the "speak to multiple reflector" part. > >> How would this work, the reflector is defined by the your_discr of > >> the outgoing packet, so how can multiple reflectors react on the BFD > >> packet (?). > >> Some kind of multicast or multipoint transport with a "multicast > >> discriminator"? > >> > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govindan > >> (venggovi) > >> wrote: > >>> Hello Manav/ all, > >>> I beg to differ here - while BFD relies on using UDP port numbers > >>> to demux packet types (Async or Echo), there is currently no notion > >>> of interpreting bits differently based on UDP destination port number= s. > >>> IMHO, it may be cleaner to consider defining a packet format of > >>> S-BFD Async afresh instead of re-defining BFD Async [RFC5880], while > >>> still using the UDP destination port to demux the packet type. > >>> This could provide an opportunity to revisit the entire Async header > >>> to reclaim/ add additional bit(s). Two candidates could be (a) the M > >>> bit which was intended for P2MP sessions (the Initiator ->Reflector > >>> model proposed by S-BFD is already MP2P) (b) the > >>> RequiredMinEchoRxInterval given that S-BFD defines Async only. > >>> PS> The above two candidates are mere examples to make the case for > >>> redefining the header and not proposals by themselves. > >>> Thanks > >>> Prasad > >>> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, > >>> Manav (Manav) > >>> Sent: Monday, March 10, 2014 5:02 AM > >>> To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK > MUDIGONDA > >>> (mmudigon); rtg-bfd@ietf.org > >>> Subject: RE: Loop Prevention in S-BFD > >>> (draft-akiya-bfd-seamless-base) > >>> > >>> Hi Santosh, > >>> > >>> Seamless BFD uses a new UDP port and that should be good enough to > >>> overload the D bit. I don't think we should be revising the version > >>> number -- at least not based on what I have heard till now. > >>> > >>> Cheers, Manav > >>> > >>>> -----Original Message----- > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>>> Santosh P K > >>>> Sent: Sunday, March 09, 2014 9:18 PM > >>>> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA > >> (mmudigon); > >>>> rtg-bfd@ietf.org > >>>> Subject: RE: Loop Prevention in S-BFD > >>>> (draft-akiya-bfd-seamless-base) > >>>> > >>>> I prefer D-bit option too. Simply because it is clean. D-bit loses > >>>> its meaning in S-BFD context and I don't think it will be used. > >>>> Only question is do we need to come up with a new version to use D- > bit? > >>>> > >>>> Thanks > >>>> Santosh P K > >>>> > >>>>> -----Original Message----- > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>>> Akiya > >>>>> (nobo) > >>>>> Sent: Sunday, March 09, 2014 7:03 PM > >>>>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg- > bfd@ietf.org > >>>>> Subject: RE: Loop Prevention in S-BFD > >>>>> (draft-akiya-bfd-seamless-base) > >>>>> > >>>>> Hi Mallik, Greg, [S-]BFDers, > >>>>> > >>>>> Please see in-line. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >>>>>> Sent: Saturday, March 08, 2014 4:43 PM > >>>>>> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- > >>>> bfd@ietf.org > >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > >>>> base) > >>>>>> > >>>>>> Dear Mallik, et. al, > >>>>>> apologies for being terribly behind on processing mail queue. > >>>>>> I was to propose use of another well-known UDP port for S-BFD but > >>>> then > >>>>>> I looked closer at RFC 5881. > >>>>> > >>>>> S-BFD proposes to use a new well-known UDP port (starting from > >>>>> base- > >>>> 02 ... > >>>>> sorry doc is still not very clear, but we've done major facelift > >>>>> on > >>>>> - > >>>> 03, which is to > >>>>> be submitted after loop/security discussions). And since different > >>>> UDP ports, > >>>>> even if were to change meaning of some fields of BFD control > >>>>> header > >>>> (ex: D bit > >>>>> interpretation), I don't feel that up versioning is absolutely > >>>> required. We could, > >>>>> but we could also avoid. > >>>>> > >>>>>> I think that we may use UDP source port of S- BFD packet received > >>>> by a > >>>>>> reflector as UDP destination port in reflected packet to break > >>>>>> the spoofed loop. > >>>>> > >>>>> Regarding usage of source UDP port to break the loop, true that's > >>>> another > >>>>> possibility. This should definitely be listed as one of the options= . > >>>> It would require > >>>>> that (dest UDP port !=3D src UDP port) ... and solution is outside > >>>>> of > >>>> BFD control > >>>>> header (do we ever want to do IP-less?). > >>>>> > >>>>>> If not that, then Option #1 but with new version (I think we'll > >>>> need > >>>>>> new version # anyway). > >>>>> > >>>>> I'm glad to see that you also prefer option #1. I recommend we > >>>>> move > >>>> forward > >>>>> with this, but list all other options in the appendix and keep the > >>>> discussion open > >>>>> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, > >>>>> what > >>>> do you > >>>>> think? > >>>>> > >>>>> -Nobo > >>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Greg > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>>>>> Akiya > >>>>>> (nobo) > >>>>>> Sent: Saturday, March 08, 2014 10:46 AM > >>>>>> To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- > >>>> base) > >>>>>> > >>>>>> Hi Mallik, et al, > >>>>>> > >>>>>> My preference: > >>>>>> > >>>>>> 1 > 2 > 3 > >>>>>> > >>>>>> Reasons: > >>>>>> > >>>>>> [3] Deviating discriminator by reflector session - Proposed will > >>>>>> prevent a single S-BFD session to speak to multiple reflectors > >>>> (cannot > >>>>>> do reply demux'ing), if implementation wants to do this or if > >>>>>> there > >>>> is > >>>>>> ever such use- case. > >>>>>> > >>>>>> [2] State - No strong opposition here, but just looks cleaner for > >>>>>> S-BFD initiator to reflect session state in state field of > >>>>>> packets > >>>> sent. > >>>>>> > >>>>>> [1] D bit - I can't think of any reason why S-BFD initiator wants > >>>> to > >>>>>> set D bit in packet to reflector session that is stateless. If S- > >>>> BFD > >>>>>> initiator is not interested in receiving back any response, S-BFD > >>>>>> initiator can simply "not send". Thus, there is no issue with > >>>> changing > >>>>>> the meaning of D bit in S-BFD context. > >>>>>> > >>>>>> -Nobo > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>>> MALLIK > >>>>>>> MUDIGONDA (mmudigon) > >>>>>>> Sent: Friday, March 07, 2014 7:58 AM > >>>>>>> To: rtg-bfd@ietf.org > >>>>>>> Subject: Loop Prevention in S-BFD > >>>>>>> (draft-akiya-bfd-seamless-base) > >>>>>>> > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Loop prevention > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> > >>>>>>> Description: > >>>>>>> > >>>>>>> Consider a scenario where we have two nodes and both are S-BFD > >>>> capable. > >>>>>>> > >>>>>>> > >>>>>>> Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) > >>>>>>> | > >>>>>>> | > >>>>>>> Man in the Middle (MiM) > >>>>>>> > >>>>>>> Node A reserved discriminator 0x01010101 and will have a > >>>> reflector > >>>>>>> session in listening mode. Similarly Node B reserved > >>>> discriminator > >>>>>>> 0x02020202 for its reflector session. > >>>>>>> > >>>>>>> Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, > >>>>>> YourDisc > >>>>>>> =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When > >>>> this > >>>>>>> packet reaches Node B, the reflector session on Node B will swap > >>>> the > >>>>>>> discriminators and IP addresses of the received packet and > >>>> reflect > >>>>>>> it back, since YourDisc of the received packet matched with > >>>> reserved > >>>>>>> discriminator of Node B. The reflected packet that reached Node > >>>>>>> A will have > >>>>>>> MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of > >>>>>>> the received packet matched the reserved discriminator of Node > >>>>>>> A, > >>>> Node A > >>>>>>> will swap the discriminators and reflects the packet back to > >>>>>>> Node > >>>> B. > >>>>>>> Since reflectors MUST set the TTL of the reflected packets to > >>>> 255, > >>>>>>> the above scenario will result in an infinite loop with just one > >>>>>>> malicious packet injected from MiM. > >>>>>>> > >>>>>>> FYI: Packet fields do not carry any direction information, i.e., > >>>> if > >>>>>>> this is Ping packet or reply packet. > >>>>>>> > >>>>>>> Solutions > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> > >>>>>>> The current proposals are: > >>>>>>> > >>>>>>> 1. Overload "D" bit (Demand mode bit). > >>>>>>> > >>>>>>> Initiator always sets the 'D' bit and reflector > >>>> clears it. This > >>>>>> way > >>>>>>> we can identify if a received packet was a reflected packet > >>>>>>> and avoid reflecting it back. However this changes > >>>> the > >>>>>>> interpretation of 'D' bit. > >>>>>>> > >>>>>>> 2. Use of State field in the BFD control packets: > >>>>>>> > >>>>>>> Initiator will always send packets with State set to > >>>> "DOWN" > >>>>>>> and reflector will send back packets with state field set to "UP. > >>>>>>> Reflectors will never reflect any packets with state > >>>> as "UP". > >>>>>>> However the only issue is the use of state field differently i.e. > >>>>>>> state in the S-BFD control packet from initiator does > >>>> not > >>>>>>> reflect the local state which is anyway not significant at > >>>> reflector. > >>>>>>> > >>>>>>> 3. Use of local discriminator as My Disc at reflector: > >>>>>>> > >>>>>>> Reflector will always fill in My Discriminator with a > >>>> locally > >>>>>>> allocated discriminator value (not reserved discriminators) and > >>>> will > >>>>>>> not copy it from the received packet. > >>>>>>> > >>>>>>> Please share your thoughts on the proposals. > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> Regards > >>>>>>> Mallik > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > > From nobody Wed Mar 12 06:06:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97201A070E for ; Wed, 12 Mar 2014 05:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj6xfHlsfQ8F for ; Wed, 12 Mar 2014 05:43:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E1EE21A096E for ; Wed, 12 Mar 2014 05:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51155; q=dns/txt; s=iport; t=1394628217; x=1395837817; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=f1YjapPmQ7YyoHKpuv3n3TGKRzblIQaRLlIYzYbd2i8=; b=mN+ZdfXtxT167oo6FctHerj1AEtMZIJJ+2gOhDljhHLr1FWKYi+USTyJ IFiuE1o9QmHqatuVl0ne6Ip/RQxCPD7frBAqfmMYdPs4KjVs8KlISPCo3 R1j64iHi09/dbKI6qZCZ1rSq0QMBfRi9OIDYKjG13wRSmH81+8Awj5/Ea 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAHRVIFOtJXHA/2dsb2JhbABQCoJCRIESvV6Dc4EbFnSCJQEBAQMBGgEMUgUHBgEIEQMBAQEBIAEGJhMUCQgCBAENBRuHVgjRcBeOAAsBAT4RBwaEMgSOc4lSki2DLYFpBgMXIg X-IronPort-AV: E=Sophos;i="4.97,637,1389744000"; d="scan'208,217";a="309797037" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 12 Mar 2014 12:43:35 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2CChZ5Q024073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 12:43:35 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 07:43:35 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , Marc Binderberger Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgAB/pvCAALKxgA== Date: Wed, 12 Mar 2014 12:43:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF4653961C536mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/C6c0l1tjGKR0KVQJchQUrA-UsT4 X-Mailman-Approved-At: Wed, 12 Mar 2014 06:06:23 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 12:43:50 -0000 --_000_CF4653961C536mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, I think we need to define the packet type in SBFD draft again and update th= e interpretation of 'D' bit alone in the new draft clearly mentioning that = implementations conforming to SBFD draft should interpret 'D' bit for ident= ifying Request or Reflected packets. This will be similar to the State Mach= ine diagram that we added removing the INIT state. Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Wednesday 12 March 2014 6:06 PM To: Marc Binderberger > Cc: "Vengada Prasad Govindan (venggovi)" >, "Bhatia, Manav (Manav)" >, Santosh P K >, Gregory Mirsky >, Cisco Employee >, "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Marc, -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Tuesday, March 11, 2014 7:57 PM To: Nobo Akiya (nobo) Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello Nobo et al., > S-BFD draft can override the meaning of D-bit in the context of S-BFD > only. We do not need to go back to RFC5880/RFC5881 and make changes. This is an interesting point: can we? Yes, S-BFD base document can update RFC5880 wrt D bit definition and proced= ures. i.e. For S-BFD, meaning and procedure is foobar. For all other BFD types, r= emains as defined in RFC5880. -Nobo Technically I like to have a flag to separate the "ping" from the "pong". Simple logic. Redefining a packet definition, not "from here on" but in parallel to the still valid RFC5880 seems somewhat odd to me. Do we have examples in IETF for this? Regards, Marc On Tue, 11 Mar 2014 14:27:41 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, Mach, > > Thanks for comments! > > Combining the responses into a single thread. > > [Marc wrote] >>> [3] Deviating discriminator by reflector session - Proposed will >>> prevent a single S-BFD session to speak to multiple reflectors >>> (cannot do reply demux'ing), if implementation wants to do this or >>> if there is ever such use-case. >> >> I admit I haven't understood the "speak to multiple reflector" part. >> How would this work, the reflector is defined by the your_discr of >> the outgoing packet, so how can multiple reflectors react on the BFD >> packet (?). >> Some kind of multicast or multipoint transport with a "multicast >> discriminator"? > > I wasn't thinking multicast, but fuzzy/vague unicast possibilities. > > [Mac wrote] >>> If a single initiator is to talk to multiple reflectors (a, b, c), >>> then my_discrim (x) may be the same for BFD packets sent to (a, b, c). >>> When reply from reflectors >> >> I'd recommend not to allow the same my_discrim for multiple reflectors. >> Consider that there are scenarios that multiple S-BFD sessions >> between the same initiator and reflector, where it requires that the >> my_discrim should be different for different session. Although the >> same my_discrim for different reflectiors is techniall workable, this >> may make the implementation complex. > > Agree. Such support shouldn't be a MUST, but I'm just not convinced > that we want to strictly disallow this in the protocol. > > [Marc wrote] >>> IMHO, it may be cleaner to consider defining a packet >>> format of S-BFD Async afresh instead of re-defining BFD Async >>> [RFC5880], while still using the UDP destination port to demux the packet type. >> >> Maybe this is the main point: by re-using the D bit it would not be >> the >> RFC5880 packet anymore but a different packet (albeit a small difference= ). >> And looking into the Demand parts of 5880 I don't think reusing "Demand" >> for S-BFD will fit well. > > Agree. > >> One could go back (must go back?) to RFC5880 and declare that the D >> bit definition depends on the session type, leave it otherwise >> undefined in >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new >> use in the S-BFD document. That would be cleaner, IMHO. But is also a >> prohibitive amount of work. > > S-BFD draft can override the meaning of D-bit in the context of S-BFD > only. We do not need to go back to RFC5880/RFC5881 and make changes. > >> >> (the software change for generic CPU to re-interpret the D bit for >> S-BFD is likely trivial. I like this aspect. Not so sure about your >> NP though. And your ASIC may need a re-spin. It's always the same >> problem with re-defining something that is already defined). >> >> For the introduction of a new version - I got fierce rejection when I >> proposed it a while ago :-) . We probably would want to introduce >> more changes then, remember the "want more flags" discussion we had. > > I remember this very well :) > > Which is why I'm pushing to avoid that path, until WG consensus shows > absolute need to do so. > > -Nobo > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, March 10, 2014 6:26 PM >> To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo) >> Cc: Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK >> MUDIGONDA (mmudigon); rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hello Prasad, Nobo et al., >> >> >>> IMHO, it may be cleaner to consider defining a packet >>> format of S-BFD Async afresh instead of re-defining BFD Async >>> [RFC5880], while still using the UDP destination port to demux the packet type. >> >> Maybe this is the main point: by re-using the D bit it would not be >> the >> RFC5880 packet anymore but a different packet (albeit a small difference= ). >> And looking into the Demand parts of 5880 I don't think reusing "Demand" >> for S-BFD will fit well. >> One could go back (must go back?) to RFC5880 and declare that the D >> bit definition depends on the session type, leave it otherwise >> undefined in >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new >> use in the S-BFD document. That would be cleaner, IMHO. But is also a >> prohibitive amount of work. >> >> (the software change for generic CPU to re-interpret the D bit for >> S-BFD is likely trivial. I like this aspect. Not so sure about your >> NP though. And your ASIC may need a re-spin. It's always the same >> problem with re-defining something that is already defined). >> >> For the introduction of a new version - I got fierce rejection when I >> proposed it a while ago :-) . We probably would want to introduce >> more changes then, remember the "want more flags" discussion we had. >> >> >>> [3] Deviating discriminator by reflector session - Proposed will >>> prevent a single S-BFD session to speak to multiple reflectors >>> (cannot do reply demux'ing), if implementation wants to do this or >>> if there is ever such use-case. >> >> I admit I haven't understood the "speak to multiple reflector" part. >> How would this work, the reflector is defined by the your_discr of >> the outgoing packet, so how can multiple reflectors react on the BFD >> packet (?). >> Some kind of multicast or multipoint transport with a "multicast >> discriminator"? >> >> >> >> Regards, Marc >> >> >> >> >> On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govindan >> (venggovi) >> wrote: >>> Hello Manav/ all, >>> I beg to differ here - while BFD relies on using UDP port numbers >>> to demux packet types (Async or Echo), there is currently no notion >>> of interpreting bits differently based on UDP destination port numbers. >>> IMHO, it may be cleaner to consider defining a packet format of >>> S-BFD Async afresh instead of re-defining BFD Async [RFC5880], while >>> still using the UDP destination port to demux the packet type. >>> This could provide an opportunity to revisit the entire Async header >>> to reclaim/ add additional bit(s). Two candidates could be (a) the M >>> bit which was intended for P2MP sessions (the Initiator ->Reflector >>> model proposed by S-BFD is already MP2P) (b) the >>> RequiredMinEchoRxInterval given that S-BFD defines Async only. >>> PS> The above two candidates are mere examples to make the case for >>> redefining the header and not proposals by themselves. >>> Thanks >>> Prasad >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, >>> Manav (Manav) >>> Sent: Monday, March 10, 2014 5:02 AM >>> To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA >>> (mmudigon); rtg-bfd@ietf.org >>> Subject: RE: Loop Prevention in S-BFD >>> (draft-akiya-bfd-seamless-base) >>> >>> Hi Santosh, >>> >>> Seamless BFD uses a new UDP port and that should be good enough to >>> overload the D bit. I don't think we should be revising the version >>> number -- at least not based on what I have heard till now. >>> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>> Santosh P K >>>> Sent: Sunday, March 09, 2014 9:18 PM >>>> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA >> (mmudigon); >>>> rtg-bfd@ietf.org >>>> Subject: RE: Loop Prevention in S-BFD >>>> (draft-akiya-bfd-seamless-base) >>>> >>>> I prefer D-bit option too. Simply because it is clean. D-bit loses >>>> its meaning in S-BFD context and I don't think it will be used. >>>> Only question is do we need to come up with a new version to use D- bit? >>>> >>>> Thanks >>>> Santosh P K >>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>> Akiya >>>>> (nobo) >>>>> Sent: Sunday, March 09, 2014 7:03 PM >>>>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg- bfd@ietf.org >>>>> Subject: RE: Loop Prevention in S-BFD >>>>> (draft-akiya-bfd-seamless-base) >>>>> >>>>> Hi Mallik, Greg, [S-]BFDers, >>>>> >>>>> Please see in-line. >>>>> >>>>>> -----Original Message----- >>>>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>>>>> Sent: Saturday, March 08, 2014 4:43 PM >>>>>> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- >>>> bfd@ietf.org >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >>>> base) >>>>>> >>>>>> Dear Mallik, et. al, >>>>>> apologies for being terribly behind on processing mail queue. >>>>>> I was to propose use of another well-known UDP port for S-BFD but >>>> then >>>>>> I looked closer at RFC 5881. >>>>> >>>>> S-BFD proposes to use a new well-known UDP port (starting from >>>>> base- >>>> 02 ... >>>>> sorry doc is still not very clear, but we've done major facelift >>>>> on >>>>> - >>>> 03, which is to >>>>> be submitted after loop/security discussions). And since different >>>> UDP ports, >>>>> even if were to change meaning of some fields of BFD control >>>>> header >>>> (ex: D bit >>>>> interpretation), I don't feel that up versioning is absolutely >>>> required. We could, >>>>> but we could also avoid. >>>>> >>>>>> I think that we may use UDP source port of S- BFD packet received >>>> by a >>>>>> reflector as UDP destination port in reflected packet to break >>>>>> the spoofed loop. >>>>> >>>>> Regarding usage of source UDP port to break the loop, true that's >>>> another >>>>> possibility. This should definitely be listed as one of the options. >>>> It would require >>>>> that (dest UDP port !=3D src UDP port) ... and solution is outside >>>>> of >>>> BFD control >>>>> header (do we ever want to do IP-less?). >>>>> >>>>>> If not that, then Option #1 but with new version (I think we'll >>>> need >>>>>> new version # anyway). >>>>> >>>>> I'm glad to see that you also prefer option #1. I recommend we >>>>> move >>>> forward >>>>> with this, but list all other options in the appendix and keep the >>>> discussion open >>>>> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, >>>>> what >>>> do you >>>>> think? >>>>> >>>>> -Nobo >>>>> >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>>>> Akiya >>>>>> (nobo) >>>>>> Sent: Saturday, March 08, 2014 10:46 AM >>>>>> To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >>>> base) >>>>>> >>>>>> Hi Mallik, et al, >>>>>> >>>>>> My preference: >>>>>> >>>>>> 1 > 2 > 3 >>>>>> >>>>>> Reasons: >>>>>> >>>>>> [3] Deviating discriminator by reflector session - Proposed will >>>>>> prevent a single S-BFD session to speak to multiple reflectors >>>> (cannot >>>>>> do reply demux'ing), if implementation wants to do this or if >>>>>> there >>>> is >>>>>> ever such use- case. >>>>>> >>>>>> [2] State - No strong opposition here, but just looks cleaner for >>>>>> S-BFD initiator to reflect session state in state field of >>>>>> packets >>>> sent. >>>>>> >>>>>> [1] D bit - I can't think of any reason why S-BFD initiator wants >>>> to >>>>>> set D bit in packet to reflector session that is stateless. If S- >>>> BFD >>>>>> initiator is not interested in receiving back any response, S-BFD >>>>>> initiator can simply "not send". Thus, there is no issue with >>>> changing >>>>>> the meaning of D bit in S-BFD context. >>>>>> >>>>>> -Nobo >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>> MALLIK >>>>>>> MUDIGONDA (mmudigon) >>>>>>> Sent: Friday, March 07, 2014 7:58 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Loop Prevention in S-BFD >>>>>>> (draft-akiya-bfd-seamless-base) >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Loop prevention >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> Description: >>>>>>> >>>>>>> Consider a scenario where we have two nodes and both are S-BFD >>>> capable. >>>>>>> >>>>>>> >>>>>>> Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) >>>>>>> | >>>>>>> | >>>>>>> Man in the Middle (MiM) >>>>>>> >>>>>>> Node A reserved discriminator 0x01010101 and will have a >>>> reflector >>>>>>> session in listening mode. Similarly Node B reserved >>>> discriminator >>>>>>> 0x02020202 for its reflector session. >>>>>>> >>>>>>> Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, >>>>>> YourDisc >>>>>>> =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When >>>> this >>>>>>> packet reaches Node B, the reflector session on Node B will swap >>>> the >>>>>>> discriminators and IP addresses of the received packet and >>>> reflect >>>>>>> it back, since YourDisc of the received packet matched with >>>> reserved >>>>>>> discriminator of Node B. The reflected packet that reached Node >>>>>>> A will have >>>>>>> MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of >>>>>>> the received packet matched the reserved discriminator of Node >>>>>>> A, >>>> Node A >>>>>>> will swap the discriminators and reflects the packet back to >>>>>>> Node >>>> B. >>>>>>> Since reflectors MUST set the TTL of the reflected packets to >>>> 255, >>>>>>> the above scenario will result in an infinite loop with just one >>>>>>> malicious packet injected from MiM. >>>>>>> >>>>>>> FYI: Packet fields do not carry any direction information, i.e., >>>> if >>>>>>> this is Ping packet or reply packet. >>>>>>> >>>>>>> Solutions >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> The current proposals are: >>>>>>> >>>>>>> 1. Overload "D" bit (Demand mode bit). >>>>>>> >>>>>>> Initiator always sets the 'D' bit and reflector >>>> clears it. This >>>>>> way >>>>>>> we can identify if a received packet was a reflected packet >>>>>>> and avoid reflecting it back. However this changes >>>> the >>>>>>> interpretation of 'D' bit. >>>>>>> >>>>>>> 2. Use of State field in the BFD control packets: >>>>>>> >>>>>>> Initiator will always send packets with State set to >>>> "DOWN" >>>>>>> and reflector will send back packets with state field set to "UP. >>>>>>> Reflectors will never reflect any packets with state >>>> as "UP". >>>>>>> However the only issue is the use of state field differently i.e. >>>>>>> state in the S-BFD control packet from initiator does >>>> not >>>>>>> reflect the local state which is anyway not significant at >>>> reflector. >>>>>>> >>>>>>> 3. Use of local discriminator as My Disc at reflector: >>>>>>> >>>>>>> Reflector will always fill in My Discriminator with a >>>> locally >>>>>>> allocated discriminator value (not reserved discriminators) and >>>> will >>>>>>> not copy it from the received packet. >>>>>>> >>>>>>> Please share your thoughts on the proposals. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Regards >>>>>>> Mallik >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> > --_000_CF4653961C536mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6D18860FB7A1AE44BDEFDDB4207E330C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Nobo,

I think we need to define the packet type in SBFD draft again and upda= te the interpretation of 'D' bit alone in the new draft clearly mentioning = that implementations conforming to SBFD draft should interpret 'D' bit for = identifying Request or Reflected packets. This will be similar to the State Machine diagram that we added r= emoving the INIT state. 

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Wednesday 12 March 2014 6:06 = PM
To: Marc Binderberger <marc@sniff.de>
Cc: "Vengada Prasad Govindan (= venggovi)" <venggovi@cisco.co= m>, "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, Santosh P K <santoshpk@juniper.net= >, Gregory Mirsky <gre= gory.mirsky@ericsson.com>, Cisco Employee <mmudigon@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Hi Marc,

-----Original Message-----
From: Marc Binderberger [mailto:marc@= sniff.de]
Sent: Tuesday, March 11, 2014 7:57 PM
To: Nobo Akiya (nobo)
Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh= P
K; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
Hello Nobo et al.,
> S-BFD draft can override the meaning of D-bit in the context of S= -BFD
> only. We do not need to go back to RFC5880/RFC5881 and make chang= es.
This is an interesting point: can we?

Yes, S-BFD base document can update RFC5880 wrt D bit definition and p= rocedures.
i.e. For S-BFD, meaning and procedure is foobar. For all other BFD typ= es, remains as defined in RFC5880.

-Nobo

Technically I like to have a flag to separate the "ping" fro= m the "pong".
Simple logic. Redefining a packet definition, not "from here on&q= uot; but in
parallel to the still valid RFC5880 seems somewhat odd to me. Do we ha= ve
examples in IETF for this?
Regards, Marc
On Tue, 11 Mar 2014 14:27:41 +0000, Nobo Akiya (nobo) wrote:
> Hi Marc, Mach,
>
> Thanks for comments!
>
> Combining the responses into a single thread.
>
> [Marc wrote]
>>> [3] Deviating discriminator by reflector session - Propos= ed will
>>> prevent a single S-BFD session to speak to multiple refle= ctors
>>> (cannot do reply demux'ing), if implementation wants to d= o this or
>>> if there is ever such use-case.
>>
>> I admit I haven't understood the "speak to multiple refl= ector" part.
>> How would this work, the reflector is defined by the your_dis= cr of
>> the outgoing packet, so how can multiple reflectors react on = the BFD
>> packet (?).
>> Some kind of multicast or multipoint transport with a "m= ulticast
>> discriminator"?
>
> I wasn't thinking multicast, but fuzzy/vague unicast possibilitie= s.
>
> [Mac wrote]
>>> If a single initiator is to talk to multiple reflectors (= a, b, c),
>>> then my_discrim (x) may be the same for BFD packets sent = to (a, b, c).
>>> When reply from reflectors
>>
>> I'd recommend not to allow the same my_discrim for multiple r= eflectors.
>> Consider that there are scenarios that multiple S-BFD session= s
>> between the same initiator and reflector, where it requires t= hat the
>> my_discrim should be different for different session. Althoug= h the
>> same my_discrim for different reflectiors is techniall workab= le, this
>> may make the implementation complex.
>
> Agree. Such support shouldn't be a MUST, but I'm just not convinc= ed
> that we want to strictly disallow this in the protocol.
>
> [Marc wrote]
>>>         &nbs= p;IMHO, it may be cleaner to consider defining a packet
>>> format of S-BFD Async afresh instead of re-defining BFD A= sync
>>> [RFC5880], while still using the UDP destination port to = demux the
packet type.
>>
>> Maybe this is the main point: by re-using the D bit it would = not be
>> the
>> RFC5880 packet anymore but a different packet (albeit a small= difference).
>> And looking into the Demand parts of 5880 I don't think reusi= ng
"Demand"
>> for S-BFD will fit well.
>
> Agree.
>
>> One could go back (must go back?) to RFC5880 and declare that= the D
>> bit definition depends on the session type, leave it otherwis= e
>> undefined in
>> RFC5880 and re-define today's (D)emand use in RFC5881. And th= e new
>> use in the S-BFD document. That would be cleaner, IMHO. But i= s also a
>> prohibitive amount of work.
>
> S-BFD draft can override the meaning of D-bit in the context of S= -BFD
> only. We do not need to go back to RFC5880/RFC5881 and make chang= es.
>
>>
>> (the software change for generic CPU to re-interpret the D bi= t for
>> S-BFD is likely trivial. I like this aspect. Not so sure abou= t your
>> NP though. And your ASIC may need a re-spin. It's always the = same
>> problem with re-defining something that is already defined).<= /div>
>>
>> For the introduction of a new version - I got fierce rejectio= n when I
>> proposed it a while ago :-) .  We probably would wa= nt to introduce
>> more changes then, remember the "want more flags" d= iscussion we had.
>
> I remember this very well :)
>
> Which is why I'm pushing to avoid that path, until WG consensus s= hows
> absolute need to do so.
>
> -Nobo
>
>> -----Original Message-----
>> From: Marc Binderberger [mai= lto:marc@sniff.de]
>> Sent: Monday, March 10, 2014 6:26 PM
>> To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo)
>> Cc: Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLI= K
>> MUDIGONDA (mmudigon); rtg= -bfd@ietf.org
>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamle= ss-base)
>>
>> Hello Prasad, Nobo et al.,
>>
>>
>>>         &nbs= p;IMHO, it may be cleaner to consider defining a packet
>>> format of S-BFD Async afresh instead of re-defining BFD A= sync
>>> [RFC5880], while still using the UDP destination port to = demux the
packet type.
>>
>> Maybe this is the main point: by re-using the D bit it would = not be
>> the
>> RFC5880 packet anymore but a different packet (albeit a small= difference).
>> And looking into the Demand parts of 5880 I don't think reusi= ng
"Demand"
>> for S-BFD will fit well.
>> One could go back (must go back?) to RFC5880 and declare that= the D
>> bit definition depends on the session type, leave it otherwis= e
>> undefined in
>> RFC5880 and re-define today's (D)emand use in RFC5881. And th= e new
>> use in the S-BFD document. That would be cleaner, IMHO. But i= s also a
>> prohibitive amount of work.
>>
>> (the software change for generic CPU to re-interpret the D bi= t for
>> S-BFD is likely trivial. I like this aspect. Not so sure abou= t your
>> NP though. And your ASIC may need a re-spin. It's always the = same
>> problem with re-defining something that is already defined).<= /div>
>>
>> For the introduction of a new version - I got fierce rejectio= n when I
>> proposed it a while ago :-) .  We probably would wa= nt to introduce
>> more changes then, remember the "want more flags" d= iscussion we had.
>>
>>
>>> [3] Deviating discriminator by reflector session - Propos= ed will
>>> prevent a single S-BFD session to speak to multiple refle= ctors
>>> (cannot do reply demux'ing), if implementation wants to d= o this or
>>> if there is ever such use-case.
>>
>> I admit I haven't understood the "speak to multiple refl= ector" part.
>> How would this work, the reflector is defined by the your_dis= cr of
>> the outgoing packet, so how can multiple reflectors react on = the BFD
>> packet (?).
>> Some kind of multicast or multipoint transport with a "m= ulticast
>> discriminator"?
>>
>>
>>
>> Regards, Marc
>>
>>
>>
>>
>> On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govind= an
>> (venggovi)
>> wrote:
>>> Hello Manav/ all,
>>>   I beg to differ here - while BFD relies on us= ing UDP port numbers
>>> to demux packet types (Async or Echo), there is currently= no notion
>>> of interpreting bits differently based on UDP destination= port numbers.
>>> IMHO, it may be cleaner to consider defining a packet for= mat of
>>> S-BFD Async afresh instead of re-defining BFD Async [RFC5= 880], while
>>> still using the UDP destination port to demux the packet = type.
>>> This could provide an opportunity to revisit the entire A= sync header
>>> to reclaim/ add additional bit(s). Two candidates could b= e (a) the M
>>> bit which was intended for P2MP sessions (the Initiator -= >Reflector
>>> model proposed by S-BFD is already MP2P) (b) the
>>> RequiredMinEchoRxInterval given that S-BFD defines Async = only.
>>> PS> The above two candidates are mere examples to make= the case for
>>> redefining the header and not proposals by themselves.
>>> Thanks
>>> Prasad
>>>
>>> -----Original Message-----
>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia,
>>> Manav (Manav)
>>> Sent: Monday, March 10, 2014 5:02 AM
>>> To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLI= K
MUDIGONDA
>>> (mmudigon); rtg-bfd@i= etf.org
>>> Subject: RE: Loop Prevention in S-BFD
>>> (draft-akiya-bfd-seamless-base)
>>>
>>> Hi Santosh,
>>>
>>> Seamless BFD uses a new UDP port and that should be good = enough to
>>> overload the D bit. I don't  think we should be= revising the version
>>> number -- at least not based on what I have heard till no= w.
>>>
>>> Cheers, Manav
>>>
>>>> -----Original Message-----
>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
>>>> Santosh P K
>>>> Sent: Sunday, March 09, 2014 9:18 PM
>>>> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGON= DA
>> (mmudigon);
>>>> Subject: RE: Loop Prevention in S-BFD
>>>> (draft-akiya-bfd-seamless-base)
>>>>
>>>> I prefer D-bit option too. Simply because it is clean= . D-bit loses
>>>> its meaning in S-BFD context and I don't think it wil= l be used.
>>>> Only question is do we need to come up with a new ver= sion to use D-
bit?
>>>>
>>>> Thanks
>>>> Santosh P K
>>>>
>>>>> -----Original Message-----
>>>> Akiya
>>>>> (nobo)
>>>>> Sent: Sunday, March 09, 2014 7:03 PM
>>>>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); = rtg-
>>>>> Subject: RE: Loop Prevention in S-BFD
>>>>> (draft-akiya-bfd-seamless-base)
>>>>>
>>>>> Hi Mallik, Greg, [S-]BFDers,
>>>>>
>>>>> Please see in-line.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
>>>>>> Sent: Saturday, March 08, 2014 4:43 PM
>>>>>> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmud= igon); rtg-
>>>> bfd@ietf.org
>>>>>> Subject: RE: Loop Prevention in S-BFD (draft-= akiya-bfd-seamless-
>>>> base)
>>>>>>
>>>>>> Dear Mallik, et. al,
>>>>>> apologies for being terribly behind on proces= sing mail queue.
>>>>>> I was to propose use of another well-known UD= P port for S-BFD but
>>>> then
>>>>>> I looked closer at RFC 5881.
>>>>>
>>>>> S-BFD proposes to use a new well-known UDP port (= starting from
>>>>> base-
>>>> 02 ...
>>>>> sorry doc is still not very clear, but we've done= major facelift
>>>>> on
>>>>> -
>>>> 03, which is to
>>>>> be submitted after loop/security discussions). An= d since different
>>>> UDP ports,
>>>>> even if were to change meaning of some fields of = BFD control
>>>>> header
>>>> (ex: D bit
>>>>> interpretation), I don't feel that up versioning = is absolutely
>>>> required. We could,
>>>>> but we could also avoid.
>>>>>
>>>>>> I think that we may use UDP source port of S-= BFD packet received
>>>> by a
>>>>>> reflector as UDP destination  port = in reflected packet to break
>>>>>> the spoofed loop.
>>>>>
>>>>> Regarding usage of source UDP port to break the l= oop, true that's
>>>> another
>>>>> possibility. This should definitely be listed as = one of the options.
>>>> It would require
>>>>> that (dest UDP port !=3D src UDP port) ... and so= lution is outside
>>>>> of
>>>> BFD control
>>>>> header (do we ever want to do IP-less?).
>>>>>
>>>>>> If not that, then Option #1 but with new vers= ion (I think we'll
>>>> need
>>>>>> new version # anyway).
>>>>>
>>>>> I'm glad to see that you also prefer option #1. I= recommend we
>>>>> move
>>>> forward
>>>>> with this, but list all other options in the appe= ndix and keep the
>>>> discussion open
>>>>> for BFDers to comment/discuss further. Mallik, Gr= eg, [S-]BFDers,
>>>>> what
>>>> do you
>>>>> think?
>>>>>
>>>>> -Nobo
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Greg
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo
>>>>>> Akiya
>>>>>> (nobo)
>>>>>> Sent: Saturday, March 08, 2014 10:46 AM
>>>>>> To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
>>>>>> Subject: RE: Loop Prevention in S-BFD (draft-= akiya-bfd-seamless-
>>>> base)
>>>>>>
>>>>>> Hi Mallik, et al,
>>>>>>
>>>>>> My preference:
>>>>>>
>>>>>> 1 > 2 > 3
>>>>>>
>>>>>> Reasons:
>>>>>>
>>>>>> [3] Deviating discriminator by reflector sess= ion - Proposed will
>>>>>> prevent a single S-BFD session to speak to mu= ltiple reflectors
>>>> (cannot
>>>>>> do reply demux'ing), if implementation wants = to do this or if
>>>>>> there
>>>> is
>>>>>> ever such use- case.
>>>>>>
>>>>>> [2] State - No strong opposition here, but ju= st looks cleaner for
>>>>>> S-BFD initiator to reflect session state in s= tate field of
>>>>>> packets
>>>> sent.
>>>>>>
>>>>>> [1] D bit - I can't think of any reason why S= -BFD initiator wants
>>>> to
>>>>>> set D bit in packet to reflector session that= is stateless. If S-
>>>> BFD
>>>>>> initiator is not interested in receiving back= any response, S-BFD
>>>>>> initiator can simply "not send". Th= us, there is no issue with
>>>> changing
>>>>>> the meaning of D bit in S-BFD context.
>>>>>>
>>>>>> -Nobo
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
>>>> MALLIK
>>>>>>> MUDIGONDA (mmudigon)
>>>>>>> Sent: Friday, March 07, 2014 7:58 AM
>>>>>>> To: r= tg-bfd@ietf.org
>>>>>>> Subject: Loop Prevention in S-BFD
>>>>>>> (draft-akiya-bfd-seamless-base)
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Loop prevention
>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
>>>>>>>
>>>>>>> Description:
>>>>>>>
>>>>>>> Consider a scenario where we have two nod= es and both are S-BFD
>>>> capable.
>>>>>>>
>>>>>>>
>>>>>>>      Node A= (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2)
>>>>>>> |
>>>>>>> |
>>>>>>> Man in the Middle (MiM)
>>>>>>>
>>>>>>> Node A reserved discriminator 0x01010101 = and will have a
>>>> reflector
>>>>>>> session in listening mode. Similarly Node= B reserved
>>>> discriminator
>>>>>>> 0x02020202 for its reflector session.
>>>>>>>
>>>>>>> Suppose MiM sends a spoofed packet with M= yDisc =3D 0x01010101,
>>>>>> YourDisc
>>>>>>> =3D 0x02020202, source IP as 1.1.1.1 and = dest IP as 2.2.2.2. When
>>>> this
>>>>>>> packet reaches Node B, the reflector sess= ion on Node B will swap
>>>> the
>>>>>>> discriminators and IP addresses of the re= ceived packet and
>>>> reflect
>>>>>>> it back, since YourDisc of the received p= acket matched with
>>>> reserved
>>>>>>> discriminator of Node B. The reflected pa= cket that reached Node
>>>>>>> A will have
>>>>>>> MyDdisc=3D0x02020202 and YourDisc=3D0x010= 10101. Since YourDisc of
>>>>>>> the received packet matched the reserved = discriminator of Node
>>>>>>> A,
>>>> Node A
>>>>>>> will swap the discriminators and reflects= the packet back to
>>>>>>> Node
>>>> B.
>>>>>>> Since reflectors MUST set the TTL of the = reflected packets to
>>>> 255,
>>>>>>> the above scenario will result in an infi= nite loop with just one
>>>>>>> malicious packet injected from MiM.
>>>>>>>
>>>>>>> FYI: Packet fields do not carry any direc= tion information, i.e.,
>>>> if
>>>>>>> this is Ping packet or reply packet.
>>>>>>>
>>>>>>> Solutions
>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>>
>>>>>>> The current proposals are:
>>>>>>>
>>>>>>> 1. Overload "D" bit (Demand mode bit).
>>>>>>>
>>>>>>> Initiator always sets the 'D' bit and reflector
>>>> clears it. This
>>>>>> way
>>>>>>> we can identify if a received packet was = a reflected packet
>>>>>>>       =    = and avoid reflecting it back. However this changes
>>>> the
>>>>>>> interpretation of 'D' bit.
>>>>>>>
>>>>>>> 2. Use of State field in the BFD control packets:
>>>>>>>
>>>>>>>      Initiator will always send packets with State set to
>>>> "DOWN"
>>>>>>> and reflector will send back packets with= state field set to "UP.
>>>>>>> Reflectors will never reflect any packets with state
>>>> as "UP".
>>>>>>> However the only issue is the use of stat= e field differently i.e.
>>>>>>>      state in the S-BFD control packet from initiator does
>>>> not
>>>>>>> reflect the local state which is anyway n= ot significant at
>>>> reflector.
>>>>>>>
>>>>>>> 3. Use of local discriminator as My Disc at reflector:
>>>>>>>
>>>>>>> Reflector will always fill in My Discriminator with a
>>>> locally
>>>>>>> allocated discriminator value (not reserv= ed discriminators) and
>>>> will
>>>>>>> not copy it from the received packet.
>>>>>>>
>>>>>>> Please share your thoughts on the proposa= ls.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Regards
>>>>>>> Mallik
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>

 --_000_CF4653961C536mmudigonciscocom_-- From nobody Wed Mar 12 06:06:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4731A0989 for ; Wed, 12 Mar 2014 06:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83JGt5VB7wjZ for ; Wed, 12 Mar 2014 06:02:55 -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 8D9EE1A0985 for ; Wed, 12 Mar 2014 06:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=125360; q=dns/txt; s=iport; t=1394629369; x=1395838969; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LqEhz1ziJ2tmuvZtLamvyY6dLvjjhelUrNOI/3RRfrA=; b=hatBMKTVsIU2AhhA96vxN/OIW6nRtadgUvJg7c+ey2XNf7Mfp4e+glm9 Xt2DaO5Rwp80TcTu4tVICqHQcDlrTGncyTlpy3bdU4VFjZMI0Crtz3AC4 HuE4jfUlYcI3cxsXdQy2kFV8piA6zxteTfBIF/l2718uk9imxuDoc1GpZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAGpZIFOtJXHA/2dsb2JhbABQCoJCIyE7V71fg3OBGxZ0giUBAQEDARoBDAZMBQcEAgEIEQMBAQEBChYBBgcyFAkIAgQBDQUIE4dWCAHRdReOAAsBAR4gEQYBBoMegRQEqnKDLYFpBgMXIg X-IronPort-AV: E=Sophos;i="4.97,638,1389744000"; d="scan'208,217";a="306730951" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 12 Mar 2014 13:02:47 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2CD2lsP017629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 13:02:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 08:02:46 -0500 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgAB/pvCAALKxgP//VPbw Date: Wed, 12 Mar 2014 13:02:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E090D5Axmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5d6o3ocXAh5GOJ9dSpURG2yoMAs X-Mailman-Approved-At: Wed, 12 Mar 2014 06:06:22 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 13:02:59 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E090D5Axmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, That would add value to readability, agree. -Nobo From: MALLIK MUDIGONDA (mmudigon) Sent: Wednesday, March 12, 2014 8:44 AM To: Nobo Akiya (nobo); Marc Binderberger Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P K;= Gregory Mirsky; rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Nobo, I think we need to define the packet type in SBFD draft again and update th= e interpretation of 'D' bit alone in the new draft clearly mentioning that = implementations conforming to SBFD draft should interpret 'D' bit for ident= ifying Request or Reflected packets. This will be similar to the State Mach= ine diagram that we added removing the INIT state. Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Wednesday 12 March 2014 6:06 PM To: Marc Binderberger > Cc: "Vengada Prasad Govindan (venggovi)" >, "Bhatia, Manav (Manav)" >, Santosh P K >, Gregory Mirsky >, Cisco Employee >, "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Marc, -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Tuesday, March 11, 2014 7:57 PM To: Nobo Akiya (nobo) Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello Nobo et al., > S-BFD draft can override the meaning of D-bit in the context of S-BFD > only. We do not need to go back to RFC5880/RFC5881 and make changes. This is an interesting point: can we? Yes, S-BFD base document can update RFC5880 wrt D bit definition and proced= ures. i.e. For S-BFD, meaning and procedure is foobar. For all other BFD types, r= emains as defined in RFC5880. -Nobo Technically I like to have a flag to separate the "ping" from the "pong". Simple logic. Redefining a packet definition, not "from here on" but in parallel to the still valid RFC5880 seems somewhat odd to me. Do we have examples in IETF for this? Regards, Marc On Tue, 11 Mar 2014 14:27:41 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, Mach, > > Thanks for comments! > > Combining the responses into a single thread. > > [Marc wrote] >>> [3] Deviating discriminator by reflector session - Proposed will >>> prevent a single S-BFD session to speak to multiple reflectors >>> (cannot do reply demux'ing), if implementation wants to do this or >>> if there is ever such use-case. >> >> I admit I haven't understood the "speak to multiple reflector" part. >> How would this work, the reflector is defined by the your_discr of >> the outgoing packet, so how can multiple reflectors react on the BFD >> packet (?). >> Some kind of multicast or multipoint transport with a "multicast >> discriminator"? > > I wasn't thinking multicast, but fuzzy/vague unicast possibilities. > > [Mac wrote] >>> If a single initiator is to talk to multiple reflectors (a, b, c), >>> then my_discrim (x) may be the same for BFD packets sent to (a, b, c). >>> When reply from reflectors >> >> I'd recommend not to allow the same my_discrim for multiple reflectors. >> Consider that there are scenarios that multiple S-BFD sessions >> between the same initiator and reflector, where it requires that the >> my_discrim should be different for different session. Although the >> same my_discrim for different reflectiors is techniall workable, this >> may make the implementation complex. > > Agree. Such support shouldn't be a MUST, but I'm just not convinced > that we want to strictly disallow this in the protocol. > > [Marc wrote] >>> IMHO, it may be cleaner to consider defining a packet >>> format of S-BFD Async afresh instead of re-defining BFD Async >>> [RFC5880], while still using the UDP destination port to demux the packet type. >> >> Maybe this is the main point: by re-using the D bit it would not be >> the >> RFC5880 packet anymore but a different packet (albeit a small difference= ). >> And looking into the Demand parts of 5880 I don't think reusing "Demand" >> for S-BFD will fit well. > > Agree. > >> One could go back (must go back?) to RFC5880 and declare that the D >> bit definition depends on the session type, leave it otherwise >> undefined in >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new >> use in the S-BFD document. That would be cleaner, IMHO. But is also a >> prohibitive amount of work. > > S-BFD draft can override the meaning of D-bit in the context of S-BFD > only. We do not need to go back to RFC5880/RFC5881 and make changes. > >> >> (the software change for generic CPU to re-interpret the D bit for >> S-BFD is likely trivial. I like this aspect. Not so sure about your >> NP though. And your ASIC may need a re-spin. It's always the same >> problem with re-defining something that is already defined). >> >> For the introduction of a new version - I got fierce rejection when I >> proposed it a while ago :-) . We probably would want to introduce >> more changes then, remember the "want more flags" discussion we had. > > I remember this very well :) > > Which is why I'm pushing to avoid that path, until WG consensus shows > absolute need to do so. > > -Nobo > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, March 10, 2014 6:26 PM >> To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo) >> Cc: Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK >> MUDIGONDA (mmudigon); rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hello Prasad, Nobo et al., >> >> >>> IMHO, it may be cleaner to consider defining a packet >>> format of S-BFD Async afresh instead of re-defining BFD Async >>> [RFC5880], while still using the UDP destination port to demux the packet type. >> >> Maybe this is the main point: by re-using the D bit it would not be >> the >> RFC5880 packet anymore but a different packet (albeit a small difference= ). >> And looking into the Demand parts of 5880 I don't think reusing "Demand" >> for S-BFD will fit well. >> One could go back (must go back?) to RFC5880 and declare that the D >> bit definition depends on the session type, leave it otherwise >> undefined in >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new >> use in the S-BFD document. That would be cleaner, IMHO. But is also a >> prohibitive amount of work. >> >> (the software change for generic CPU to re-interpret the D bit for >> S-BFD is likely trivial. I like this aspect. Not so sure about your >> NP though. And your ASIC may need a re-spin. It's always the same >> problem with re-defining something that is already defined). >> >> For the introduction of a new version - I got fierce rejection when I >> proposed it a while ago :-) . We probably would want to introduce >> more changes then, remember the "want more flags" discussion we had. >> >> >>> [3] Deviating discriminator by reflector session - Proposed will >>> prevent a single S-BFD session to speak to multiple reflectors >>> (cannot do reply demux'ing), if implementation wants to do this or >>> if there is ever such use-case. >> >> I admit I haven't understood the "speak to multiple reflector" part. >> How would this work, the reflector is defined by the your_discr of >> the outgoing packet, so how can multiple reflectors react on the BFD >> packet (?). >> Some kind of multicast or multipoint transport with a "multicast >> discriminator"? >> >> >> >> Regards, Marc >> >> >> >> >> On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govindan >> (venggovi) >> wrote: >>> Hello Manav/ all, >>> I beg to differ here - while BFD relies on using UDP port numbers >>> to demux packet types (Async or Echo), there is currently no notion >>> of interpreting bits differently based on UDP destination port numbers. >>> IMHO, it may be cleaner to consider defining a packet format of >>> S-BFD Async afresh instead of re-defining BFD Async [RFC5880], while >>> still using the UDP destination port to demux the packet type. >>> This could provide an opportunity to revisit the entire Async header >>> to reclaim/ add additional bit(s). Two candidates could be (a) the M >>> bit which was intended for P2MP sessions (the Initiator ->Reflector >>> model proposed by S-BFD is already MP2P) (b) the >>> RequiredMinEchoRxInterval given that S-BFD defines Async only. >>> PS> The above two candidates are mere examples to make the case for >>> redefining the header and not proposals by themselves. >>> Thanks >>> Prasad >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, >>> Manav (Manav) >>> Sent: Monday, March 10, 2014 5:02 AM >>> To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA >>> (mmudigon); rtg-bfd@ietf.org >>> Subject: RE: Loop Prevention in S-BFD >>> (draft-akiya-bfd-seamless-base) >>> >>> Hi Santosh, >>> >>> Seamless BFD uses a new UDP port and that should be good enough to >>> overload the D bit. I don't think we should be revising the version >>> number -- at least not based on what I have heard till now. >>> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>> Santosh P K >>>> Sent: Sunday, March 09, 2014 9:18 PM >>>> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA >> (mmudigon); >>>> rtg-bfd@ietf.org >>>> Subject: RE: Loop Prevention in S-BFD >>>> (draft-akiya-bfd-seamless-base) >>>> >>>> I prefer D-bit option too. Simply because it is clean. D-bit loses >>>> its meaning in S-BFD context and I don't think it will be used. >>>> Only question is do we need to come up with a new version to use D- bit? >>>> >>>> Thanks >>>> Santosh P K >>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>> Akiya >>>>> (nobo) >>>>> Sent: Sunday, March 09, 2014 7:03 PM >>>>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg- bfd@ietf.org >>>>> Subject: RE: Loop Prevention in S-BFD >>>>> (draft-akiya-bfd-seamless-base) >>>>> >>>>> Hi Mallik, Greg, [S-]BFDers, >>>>> >>>>> Please see in-line. >>>>> >>>>>> -----Original Message----- >>>>>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>>>>> Sent: Saturday, March 08, 2014 4:43 PM >>>>>> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg- >>>> bfd@ietf.org >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >>>> base) >>>>>> >>>>>> Dear Mallik, et. al, >>>>>> apologies for being terribly behind on processing mail queue. >>>>>> I was to propose use of another well-known UDP port for S-BFD but >>>> then >>>>>> I looked closer at RFC 5881. >>>>> >>>>> S-BFD proposes to use a new well-known UDP port (starting from >>>>> base- >>>> 02 ... >>>>> sorry doc is still not very clear, but we've done major facelift >>>>> on >>>>> - >>>> 03, which is to >>>>> be submitted after loop/security discussions). And since different >>>> UDP ports, >>>>> even if were to change meaning of some fields of BFD control >>>>> header >>>> (ex: D bit >>>>> interpretation), I don't feel that up versioning is absolutely >>>> required. We could, >>>>> but we could also avoid. >>>>> >>>>>> I think that we may use UDP source port of S- BFD packet received >>>> by a >>>>>> reflector as UDP destination port in reflected packet to break >>>>>> the spoofed loop. >>>>> >>>>> Regarding usage of source UDP port to break the loop, true that's >>>> another >>>>> possibility. This should definitely be listed as one of the options. >>>> It would require >>>>> that (dest UDP port !=3D src UDP port) ... and solution is outside >>>>> of >>>> BFD control >>>>> header (do we ever want to do IP-less?). >>>>> >>>>>> If not that, then Option #1 but with new version (I think we'll >>>> need >>>>>> new version # anyway). >>>>> >>>>> I'm glad to see that you also prefer option #1. I recommend we >>>>> move >>>> forward >>>>> with this, but list all other options in the appendix and keep the >>>> discussion open >>>>> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, >>>>> what >>>> do you >>>>> think? >>>>> >>>>> -Nobo >>>>> >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>>>> Akiya >>>>>> (nobo) >>>>>> Sent: Saturday, March 08, 2014 10:46 AM >>>>>> To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org >>>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless- >>>> base) >>>>>> >>>>>> Hi Mallik, et al, >>>>>> >>>>>> My preference: >>>>>> >>>>>> 1 > 2 > 3 >>>>>> >>>>>> Reasons: >>>>>> >>>>>> [3] Deviating discriminator by reflector session - Proposed will >>>>>> prevent a single S-BFD session to speak to multiple reflectors >>>> (cannot >>>>>> do reply demux'ing), if implementation wants to do this or if >>>>>> there >>>> is >>>>>> ever such use- case. >>>>>> >>>>>> [2] State - No strong opposition here, but just looks cleaner for >>>>>> S-BFD initiator to reflect session state in state field of >>>>>> packets >>>> sent. >>>>>> >>>>>> [1] D bit - I can't think of any reason why S-BFD initiator wants >>>> to >>>>>> set D bit in packet to reflector session that is stateless. If S- >>>> BFD >>>>>> initiator is not interested in receiving back any response, S-BFD >>>>>> initiator can simply "not send". Thus, there is no issue with >>>> changing >>>>>> the meaning of D bit in S-BFD context. >>>>>> >>>>>> -Nobo >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>> MALLIK >>>>>>> MUDIGONDA (mmudigon) >>>>>>> Sent: Friday, March 07, 2014 7:58 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Loop Prevention in S-BFD >>>>>>> (draft-akiya-bfd-seamless-base) >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Loop prevention >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> Description: >>>>>>> >>>>>>> Consider a scenario where we have two nodes and both are S-BFD >>>> capable. >>>>>>> >>>>>>> >>>>>>> Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) >>>>>>> | >>>>>>> | >>>>>>> Man in the Middle (MiM) >>>>>>> >>>>>>> Node A reserved discriminator 0x01010101 and will have a >>>> reflector >>>>>>> session in listening mode. Similarly Node B reserved >>>> discriminator >>>>>>> 0x02020202 for its reflector session. >>>>>>> >>>>>>> Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, >>>>>> YourDisc >>>>>>> =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When >>>> this >>>>>>> packet reaches Node B, the reflector session on Node B will swap >>>> the >>>>>>> discriminators and IP addresses of the received packet and >>>> reflect >>>>>>> it back, since YourDisc of the received packet matched with >>>> reserved >>>>>>> discriminator of Node B. The reflected packet that reached Node >>>>>>> A will have >>>>>>> MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of >>>>>>> the received packet matched the reserved discriminator of Node >>>>>>> A, >>>> Node A >>>>>>> will swap the discriminators and reflects the packet back to >>>>>>> Node >>>> B. >>>>>>> Since reflectors MUST set the TTL of the reflected packets to >>>> 255, >>>>>>> the above scenario will result in an infinite loop with just one >>>>>>> malicious packet injected from MiM. >>>>>>> >>>>>>> FYI: Packet fields do not carry any direction information, i.e., >>>> if >>>>>>> this is Ping packet or reply packet. >>>>>>> >>>>>>> Solutions >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> The current proposals are: >>>>>>> >>>>>>> 1. Overload "D" bit (Demand mode bit). >>>>>>> >>>>>>> Initiator always sets the 'D' bit and reflector >>>> clears it. This >>>>>> way >>>>>>> we can identify if a received packet was a reflected packet >>>>>>> and avoid reflecting it back. However this changes >>>> the >>>>>>> interpretation of 'D' bit. >>>>>>> >>>>>>> 2. Use of State field in the BFD control packets: >>>>>>> >>>>>>> Initiator will always send packets with State set to >>>> "DOWN" >>>>>>> and reflector will send back packets with state field set to "UP. >>>>>>> Reflectors will never reflect any packets with state >>>> as "UP". >>>>>>> However the only issue is the use of state field differently i.e. >>>>>>> state in the S-BFD control packet from initiator does >>>> not >>>>>>> reflect the local state which is anyway not significant at >>>> reflector. >>>>>>> >>>>>>> 3. Use of local discriminator as My Disc at reflector: >>>>>>> >>>>>>> Reflector will always fill in My Discriminator with a >>>> locally >>>>>>> allocated discriminator value (not reserved discriminators) and >>>> will >>>>>>> not copy it from the received packet. >>>>>>> >>>>>>> Please share your thoughts on the proposals. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Regards >>>>>>> Mallik >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> > --_000_CECE764681BE964CBE1DFF78F3CDD3941E090D5Axmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik,

 <= /p>

That would add value to r= eadability, agree.

 <= /p>

-Nobo

 <= /p>

From: MALLIK MUDIGONDA (mmudigon)
Sent: Wednesday, March 12, 2014 8:44 AM
To: Nobo Akiya (nobo); Marc Binderberger
Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santo= sh P K; Gregory Mirsky; rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hi Nobo,

 

I think we need to define the= packet type in SBFD draft again and update the interpretation of 'D' bit a= lone in the new draft clearly mentioning that implementations conforming to SBFD draft should interpret 'D' bit for identifying Request = or Reflected packets. This will be similar to the State Machine diagram tha= t we added removing the INIT state. 

 

Thanks

 

Regards

Mallik

 

From: "Nobo Akiya (nobo)" <nobo@cisco.com>
Date: Wednesday 12 March 2014 6:06 PM
To: Marc Binderberger <marc@snif= f.de>
Cc: "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, "Bhatia, Manav (M= anav)" <manav.bh= atia@alcatel-lucent.com>, Santosh P K <santoshpk@juniper.net>, Gregory Mirsky <gregory.= mirsky@ericsson.com>, Cisco Employee <mmudigon@cisco.com>, "rtg-bfd@ietf.org" <rt= g-bfd@ietf.org>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hi Marc,

 

-----Original Message-----

From: Marc Binderberger [mailto:marc@sniff.de]

Sent: Tuesday, March 11, 2014= 7:57 PM

To: Nobo Akiya (nobo)

Cc: Vengada Prasad Govindan (= venggovi); Bhatia, Manav (Manav); Santosh P

K; Gregory Mirsky; MALLIK MUD= IGONDA (mmudigon); rtg-bfd@ietf.org<= /p>

Subject: RE: Loop Prevention = in S-BFD (draft-akiya-bfd-seamless-base)

Hello Nobo et al.,=

> S-BFD draft can override= the meaning of D-bit in the context of S-BFD

> only. We do not need to = go back to RFC5880/RFC5881 and make changes.

This is an interesting point:= can we?

 

Yes, S-BFD base document can = update RFC5880 wrt D bit definition and procedures.

i.e. For S-BFD, meaning and p= rocedure is foobar. For all other BFD types, remains as defined in RFC5880.=

 

-Nobo

 

Technically I like to have a = flag to separate the "ping" from the "pong".=

Simple logic. Redefining a pa= cket definition, not "from here on" but in

parallel to the still valid R= FC5880 seems somewhat odd to me. Do we have

examples in IETF for this?

Regards, Marc

On Tue, 11 Mar 2014 14:27:41 = +0000, Nobo Akiya (nobo) wrote:

> Hi Marc, Mach,

> <= /p>

> Thanks for comments!

> <= /p>

> Combining the responses = into a single thread.

> <= /p>

> [Marc wrote]<= /span>

>>> [3] Deviating di= scriminator by reflector session - Proposed will

>>> prevent a single= S-BFD session to speak to multiple reflectors

>>> (cannot do reply= demux'ing), if implementation wants to do this or

>>> if there is ever= such use-case.

>> 

>> I admit I haven't un= derstood the "speak to multiple reflector" part.

>> How would this work,= the reflector is defined by the your_discr of

>> the outgoing packet,= so how can multiple reflectors react on the BFD

>> packet (?).

>> Some kind of multica= st or multipoint transport with a "multicast

>> discriminator"?=

> <= /p>

> I wasn't thinking multic= ast, but fuzzy/vague unicast possibilities.

> <= /p>

> [Mac wrote]

>>> If a single init= iator is to talk to multiple reflectors (a, b, c),

>>> then my_discrim = (x) may be the same for BFD packets sent to (a, b, c).

>>> When reply from = reflectors

>> 

>> I'd recommend not to= allow the same my_discrim for multiple reflectors.

>> Consider that there = are scenarios that multiple S-BFD sessions

>> between the same ini= tiator and reflector, where it requires that the

>> my_discrim should be= different for different session. Although the

>> same my_discrim for = different reflectiors is techniall workable, this

>> may make the impleme= ntation complex.

> <= /p>

> Agree. Such support shou= ldn't be a MUST, but I'm just not convinced

> that we want to strictly= disallow this in the protocol.

> <= /p>

> [Marc wrote]<= /span>

>>>   = ;       IMHO, it may be cleaner to consi= der defining a packet

>>> format of S-BFD = Async afresh instead of re-defining BFD Async

>>> [RFC5880], while= still using the UDP destination port to demux the

packet type.

>> 

>> Maybe this is the ma= in point: by re-using the D bit it would not be

>> the

>> RFC5880 packet anymo= re but a different packet (albeit a small difference).

>> And looking into the= Demand parts of 5880 I don't think reusing

"Demand"=

>> for S-BFD will fit w= ell.

> <= /p>

> Agree.=

> <= /p>

>> One could go back (m= ust go back?) to RFC5880 and declare that the D

>> bit definition depen= ds on the session type, leave it otherwise

>> undefined in

>> RFC5880 and re-defin= e today's (D)emand use in RFC5881. And the new

>> use in the S-BFD doc= ument. That would be cleaner, IMHO. But is also a

>> prohibitive amount o= f work.

> <= /p>

> S-BFD draft can override= the meaning of D-bit in the context of S-BFD

> only. We do not need to = go back to RFC5880/RFC5881 and make changes.

> <= /p>

>> 

>> (the software change= for generic CPU to re-interpret the D bit for

>> S-BFD is likely triv= ial. I like this aspect. Not so sure about your

>> NP though. And your = ASIC may need a re-spin. It's always the same

>> problem with re-defi= ning something that is already defined).

>> 

>> For the introduction= of a new version - I got fierce rejection when I

>> proposed it a while = ago :-) .  We probably would want to introduce<= /p>

>> more changes then, r= emember the "want more flags" discussion we had.

> <= /p>

> I remember this very wel= l :)

> <= /p>

> Which is why I'm pushing= to avoid that path, until WG consensus shows

> absolute need to do so.<= o:p>

> <= /p>

> -Nobo<= /p>

> <= /p>

>> -----Original Messag= e-----

>> From: Marc Binderber= ger [mailto:marc@sniff.de]<= /span>

>> Sent: Monday, March = 10, 2014 6:26 PM

>> To: Vengada Prasad G= ovindan (venggovi); Nobo Akiya (nobo)

>> Cc: Bhatia, Manav (M= anav); Santosh P K; Gregory Mirsky; MALLIK

>> MUDIGONDA (mmudigon)= ; rtg-bfd@ietf.org<= /p>

>> Subject: RE: Loop Pr= evention in S-BFD (draft-akiya-bfd-seamless-base)

>> 

>> Hello Prasad, Nobo e= t al.,

>> 

>> 

>>>   = ;       IMHO, it may be cleaner to consi= der defining a packet

>>> format of S-BFD = Async afresh instead of re-defining BFD Async

>>> [RFC5880], while= still using the UDP destination port to demux the

packet type.

>> 

>> Maybe this is the ma= in point: by re-using the D bit it would not be

>> the

>> RFC5880 packet anymo= re but a different packet (albeit a small difference).

>> And looking into the= Demand parts of 5880 I don't think reusing

"Demand"=

>> for S-BFD will fit w= ell.

>> One could go back (m= ust go back?) to RFC5880 and declare that the D

>> bit definition depen= ds on the session type, leave it otherwise

>> undefined in

>> RFC5880 and re-defin= e today's (D)emand use in RFC5881. And the new

>> use in the S-BFD doc= ument. That would be cleaner, IMHO. But is also a

>> prohibitive amount o= f work.

>> 

>> (the software change= for generic CPU to re-interpret the D bit for

>> S-BFD is likely triv= ial. I like this aspect. Not so sure about your

>> NP though. And your = ASIC may need a re-spin. It's always the same

>> problem with re-defi= ning something that is already defined).

>> 

>> For the introduction= of a new version - I got fierce rejection when I

>> proposed it a while = ago :-) .  We probably would want to introduce<= /p>

>> more changes then, r= emember the "want more flags" discussion we had.

>> 

>> 

>>> [3] Deviating di= scriminator by reflector session - Proposed will

>>> prevent a single= S-BFD session to speak to multiple reflectors

>>> (cannot do reply= demux'ing), if implementation wants to do this or

>>> if there is ever= such use-case.

>> 

>> I admit I haven't un= derstood the "speak to multiple reflector" part.

>> How would this work,= the reflector is defined by the your_discr of

>> the outgoing packet,= so how can multiple reflectors react on the BFD

>> packet (?).

>> Some kind of multica= st or multipoint transport with a "multicast

>> discriminator"?=

>> 

>> 

>> 

>> Regards, Marc

>> 

>> 

>> 

>> 

>> On Mon, 10 Mar 2014 = 07:23:45 +0000, Vengada Prasad Govindan

>> (venggovi)

>> wrote:

>>> Hello Manav/ all= ,

>>>   I be= g to differ here - while BFD relies on using UDP port numbers

>>> to demux packet = types (Async or Echo), there is currently no notion

>>> of interpreting = bits differently based on UDP destination port numbers.

>>> IMHO, it may be = cleaner to consider defining a packet format of

>>> S-BFD Async afre= sh instead of re-defining BFD Async [RFC5880], while

>>> still using the = UDP destination port to demux the packet type.

>>> This could provi= de an opportunity to revisit the entire Async header

>>> to reclaim/ add = additional bit(s). Two candidates could be (a) the M

>>> bit which was in= tended for P2MP sessions (the Initiator ->Reflector

>>> model proposed b= y S-BFD is already MP2P) (b) the

>>> RequiredMinEchoR= xInterval given that S-BFD defines Async only.

>>> PS> The above= two candidates are mere examples to make the case for

>>> redefining the h= eader and not proposals by themselves.

>>> Thanks

>>> Prasad

>>> =

>>> -----Original Me= ssage-----

>>> From: Rtg-bfd [<= a href=3D"mailto:rtg-bfd-bounces@ietf.org">mailto:rtg-bfd-bounces@ietf.org<= /a>] On Behalf Of Bhatia,

>>> Manav (Manav)

>>> Sent: Monday, Ma= rch 10, 2014 5:02 AM

>>> To: Santosh P K;= Nobo Akiya (nobo); Gregory Mirsky; MALLIK

MUDIGONDA

>>> (mmudigon); rtg-bfd@ietf.org<= /p>

>>> Subject: RE: Loo= p Prevention in S-BFD

>>> (draft-akiya-bfd= -seamless-base)

>>> =

>>> Hi Santosh,=

>>> =

>>> Seamless BFD use= s a new UDP port and that should be good enough to

>>> overload the D b= it. I don't  think we should be revising the version

>>> number -- at lea= st not based on what I have heard till now.

>>> =

>>> Cheers, Manav

>>> =

>>>> -----Origina= l Message-----

>>>> From: Rtg-bf= d [mailto:rtg-bfd-bounces@ietf.= org] On Behalf Of

>>>> Santosh P K<= o:p>

>>>> Sent: Sunday= , March 09, 2014 9:18 PM

>>>> To: Nobo Aki= ya (nobo); Gregory Mirsky; MALLIK MUDIGONDA

>> (mmudigon);

>>>> rtg-bfd@ietf.org<= /p>

>>>> Subject: RE:= Loop Prevention in S-BFD

>>>> (draft-akiya= -bfd-seamless-base)

>>>> 

>>>> I prefer D-b= it option too. Simply because it is clean. D-bit loses

>>>> its meaning = in S-BFD context and I don't think it will be used.

>>>> Only questio= n is do we need to come up with a new version to use D-

bit?

>>>> 

>>>> Thanks<= /o:p>

>>>> Santosh P K<= o:p>

>>>> 

>>>>> -----Ori= ginal Message-----

>>>>> From: Rt= g-bfd [mailto:rtg-bfd-bounces@i= etf.org] On Behalf Of Nobo

>>>> Akiya

>>>>> (nobo)

>>>>> Sent: Su= nday, March 09, 2014 7:03 PM

>>>>> To: Greg= ory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-

>>>>> Subject:= RE: Loop Prevention in S-BFD

>>>>> (draft-a= kiya-bfd-seamless-base)

>>>>>&nbs= p;

>>>>> Hi Malli= k, Greg, [S-]BFDers,

>>>>>&nbs= p;

>>>>> Please s= ee in-line.

>>>>>&nbs= p;

>>>>>> ----= -Original Message-----

>>>>>> From= : Gregory Mirsky [mailto:gre= gory.mirsky@ericsson.com]

>>>>>> Sent= : Saturday, March 08, 2014 4:43 PM

>>>>>> To: = Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg-

>>>>>> Subj= ect: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-

>>>> base)

>>>>>>=  

>>>>>> Dear= Mallik, et. al,

>>>>>> apol= ogies for being terribly behind on processing mail queue.=

>>>>>> I wa= s to propose use of another well-known UDP port for S-BFD but

>>>> then

>>>>>> I lo= oked closer at RFC 5881.

>>>>>&nbs= p;

>>>>> S-BFD pr= oposes to use a new well-known UDP port (starting from

>>>>> base-

>>>> 02 ...<= /o:p>

>>>>> sorry do= c is still not very clear, but we've done major facelift<= /p>

>>>>> on<= /o:p>

>>>>> -

>>>> 03, which is= to

>>>>> be submi= tted after loop/security discussions). And since different

>>>> UDP ports,

>>>>> even if = were to change meaning of some fields of BFD control

>>>>> header

>>>> (ex: D bit

>>>>> interpre= tation), I don't feel that up versioning is absolutely

>>>> required. We= could,

>>>>> but we c= ould also avoid.

>>>>>&nbs= p;

>>>>>> I th= ink that we may use UDP source port of S- BFD packet received

>>>> by a

>>>>>> refl= ector as UDP destination  port in reflected packet to break<= /o:p>

>>>>>> the = spoofed loop.

>>>>>&nbs= p;

>>>>> Regardin= g usage of source UDP port to break the loop, true that's=

>>>> another=

>>>>> possibil= ity. This should definitely be listed as one of the options.

>>>> It would req= uire

>>>>> that (de= st UDP port !=3D src UDP port) ... and solution is outside

>>>>> of<= /o:p>

>>>> BFD control<= o:p>

>>>>> header (= do we ever want to do IP-less?).

>>>>>&nbs= p;

>>>>>> If n= ot that, then Option #1 but with new version (I think we'll

>>>> need

>>>>>> new = version # anyway).

>>>>>&nbs= p;

>>>>> I'm glad= to see that you also prefer option #1. I recommend we

>>>>> move

>>>> forward=

>>>>> with thi= s, but list all other options in the appendix and keep the

>>>> discussion o= pen

>>>>> for BFDe= rs to comment/discuss further. Mallik, Greg, [S-]BFDers,<= /p>

>>>>> what

>>>> do you<= /o:p>

>>>>> think?

>>>>>&nbs= p;

>>>>> -Nobo

>>>>>&nbs= p;

>>>>>>=  

>>>>>>     Regards,

>>>>>>        &n= bsp;        Greg

>>>>>>=  

>>>>>> ----= -Original Message-----

>>>>>> From= : Rtg-bfd [mailto:rtg-bfd-bounc= es@ietf.org] On Behalf Of Nobo

>>>>>> Akiy= a

>>>>>> (nob= o)

>>>>>> Sent= : Saturday, March 08, 2014 10:46 AM

>>>>>> To: = MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org<= /p>

>>>>>> Subj= ect: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-

>>>> base)

>>>>>>=  

>>>>>> Hi M= allik, et al,

>>>>>>=  

>>>>>> My p= reference:

>>>>>>=  

>>>>>> 1 &g= t; 2 > 3

>>>>>>=  

>>>>>> Reas= ons:

>>>>>>=  

>>>>>> [3] = Deviating discriminator by reflector session - Proposed will

>>>>>> prev= ent a single S-BFD session to speak to multiple reflectors

>>>> (cannot=

>>>>>> do r= eply demux'ing), if implementation wants to do this or if=

>>>>>> ther= e

>>>> is

>>>>>> ever= such use- case.

>>>>>>=  

>>>>>> [2] = State - No strong opposition here, but just looks cleaner for

>>>>>> S-BF= D initiator to reflect session state in state field of

>>>>>> pack= ets

>>>> sent.

>>>>>>=  

>>>>>> [1] = D bit - I can't think of any reason why S-BFD initiator wants

>>>> to

>>>>>> set = D bit in packet to reflector session that is stateless. If S-

>>>> BFD

>>>>>> init= iator is not interested in receiving back any response, S-BFD

>>>>>> init= iator can simply "not send". Thus, there is no issue with

>>>> changing

>>>>>> the = meaning of D bit in S-BFD context.

>>>>>>=  

>>>>>> -Nob= o

>>>>>>=  

>>>>>>> = -----Original Message-----

>>>>>>> = From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of

>>>> MALLIK<= /o:p>

>>>>>>> = MUDIGONDA (mmudigon)

>>>>>>> = Sent: Friday, March 07, 2014 7:58 AM

>>>>>>> = To: rtg-bfd@ietf.org<= /p>

>>>>>>> = Subject: Loop Prevention in S-BFD

>>>>>>> = (draft-akiya-bfd-seamless-base)

>>>>>>><= o:p> 

>>>>>>><= o:p> 

>>>>>>> = Hi,

>>>>>>><= o:p> 

>>>>>>> = Loop prevention

>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>>>>>>><= o:p> 

>>>>>>> = Description:

>>>>>>><= o:p> 

>>>>>>> = Consider a scenario where we have two nodes and both are S-BFD

>>>> capable.

>>>>>>><= o:p> 

>>>>>>><= o:p> 

>>>>>>>&= nbsp;     Node A (IP 1.1.1.1) ---------------- Nod= e B (IP 2.2.2.2)

>>>>>>>        &n= bsp;            = ;            &n= bsp;     |

>>>>>>>        &n= bsp;            = ;            &n= bsp;     |

>>>>>>>        &n= bsp;            = ;      Man in the Middle (MiM)

>>>>>>><= o:p> 

>>>>>>> = Node A reserved discriminator 0x01010101 and will have a<= /p>

>>>> reflector

>>>>>>> = session in listening mode. Similarly Node B reserved

>>>> discriminato= r

>>>>>>> = 0x02020202 for its reflector session.

>>>>>>><= o:p> 

>>>>>>> = Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101,

>>>>>> Your= Disc

>>>>>>> = =3D 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When

>>>> this

>>>>>>> = packet reaches Node B, the reflector session on Node B will swap=

>>>> the

>>>>>>> = discriminators and IP addresses of the received packet and

>>>> reflect=

>>>>>>> = it back, since YourDisc of the received packet matched with

>>>> reserved

>>>>>>> = discriminator of Node B. The reflected packet that reached Node<= /span>

>>>>>>> = A will have

>>>>>>> = MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. Since YourDisc of

>>>>>>> = the received packet matched the reserved discriminator of Node

>>>>>>> = A,

>>>> Node A<= /o:p>

>>>>>>> = will swap the discriminators and reflects the packet back to

>>>>>>> = Node

>>>> B.

>>>>>>> = Since reflectors MUST set the TTL of the reflected packets to

>>>> 255,

>>>>>>> = the above scenario will result in an infinite loop with just one=

>>>>>>> = malicious packet injected from MiM.

>>>>>>><= o:p> 

>>>>>>> = FYI: Packet fields do not carry any direction information, i.e.,=

>>>> if

>>>>>>> = this is Ping packet or reply packet.

>>>>>>><= o:p> 

>>>>>>> = Solutions

>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D

>>>>>>><= o:p> 

>>>>>>> = The current proposals are:

>>>>>>><= o:p> 

>>>>>>>   1.         Overload "D" bit (Demand mode bit).

>>>>>>><= o:p> 

>>>>>>>        &n= bsp;      Initiator always sets the 'D' bit= and reflector

>>>> clears it. T= his

>>>>>> way<= o:p>

>>>>>>> = we can identify if a received packet was a reflected packet

>>>>>>>&= nbsp;              and avoid reflecting it back. However this changes=

>>>> the

>>>>>>> = interpretation of 'D' bit.

>>>>>>><= o:p> 

>>>>>>>   2.         Use of State field in the BFD control packets:

>>>>>>><= o:p> 

>>>>>>>               Initiator will always send packets with State set to

>>>> "DOWN&q= uot;

>>>>>>> = and reflector will send back packets with state field set to "UP.=

>>>>>>>        &n= bsp;      Reflectors will never reflect any= packets with state

>>>> as "UP&= quot;.

>>>>>>> = However the only issue is the use of state field differently i.e.

>>>>>>>               state in the S-BFD control packet from initiator does

>>>> not

>>>>>>> = reflect the local state which is anyway not significant at

>>>> reflector.

>>>>>>><= o:p> 

>>>>>>>   3.         Use of local discriminator as My Disc at reflector:

>>>>>>><= o:p> 

>>>>>>>        &n= bsp;      Reflector will always fill in My = Discriminator with a

>>>> locally=

>>>>>>> = allocated discriminator value (not reserved discriminators) and<= /span>

>>>> will

>>>>>>>        &n= bsp;      not copy it from the received pac= ket.

>>>>>>><= o:p> 

>>>>>>> = Please share your thoughts on the proposals.

>>>>>>><= o:p> 

>>>>>>> = Thanks

>>>>>>><= o:p> 

>>>>>>> = Regards

>>>>>>> = Mallik

>>>>>>><= o:p> 

>>>>>>><= o:p> 

>>>>>&nbs= p;

>>>>>&nbs= p;

>>>> 

>>> =

> <= /p>

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941E090D5Axmbalnx01ciscoc_-- From nobody Wed Mar 12 07:19:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DF91A06B2 for ; Wed, 12 Mar 2014 07:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNkGFMtXS9jX for ; Wed, 12 Mar 2014 07:19:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBA01A07F4 for ; Wed, 12 Mar 2014 07:19:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E11A2C345; Wed, 12 Mar 2014 10:19:03 -0400 (EDT) Date: Wed, 12 Mar 2014 10:19:03 -0400 From: Jeffrey Haas To: Mach Chen Subject: Re: Question abouth P bit setting Message-ID: <20140312141903.GI29320@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bfW7zi5NRrKbciEyOxKi4t9cGSE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 14:19:16 -0000 On Wed, Mar 12, 2014 at 06:26:19AM +0000, Mach Chen wrote: > Thanks for the detail explanation, it's clear. > > According to your and Marc's response, seems that one system could choose to set the P bit (strictly as RFC5880 says) or clear the P bit (as you said and some implementations do). The key point is that the remote system could properly process the control packet with/without P bit set. > > Ask this question, because I saw two implementations that one set the P bit and the other does not. The place this is problematic is that the P-bit expects the F-bit to be used. It can't be wholly ignored. But the procedure also means that if the F-bit is received, the poll should end. This isn't a very good fit for the usual state machine changes because multiple packets may be sent and received as the state machine transitions. My recommendation would be that poll sequences (sec. 6.5) should only be used for parameter changes outside of those part of the state machine transitioning to the Up state. A reminder from section 6: "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." -- Jeff From nobody Wed Mar 12 09:55:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35BC1A046B for ; Wed, 12 Mar 2014 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaZgQOfspZuC for ; Wed, 12 Mar 2014 09:55:51 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC761A0471 for ; Wed, 12 Mar 2014 09:55:50 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D528C2AA0F; Wed, 12 Mar 2014 16:55:42 +0000 (GMT) Date: Wed, 12 Mar 2014 09:55:41 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140312095541956142.a132bc06@sniff.de> In-Reply-To: <20140312141903.GI29320@pfrc> References: <20140312141903.GI29320@pfrc> Subject: Re: Question abouth P bit setting MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OrVyrX7xE6zsa074NyntAIc50qo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 16:55:57 -0000 Hello Jeff, hmm, I'm a bit lost :-) as I don't see the problem. The Poll sequence - sending P, receiving F - seems orthogonal to the state machine for me. It's just a synchronization mechanism on top to ensure timers are set in the right sequence. If you mean "stay out of grey zones and don't make assumptions" then I agree though :-) One could always bring the session to Up with slow timers, then start P-F to change to fast timers. Regards, Marc On Wed, 12 Mar 2014 10:19:03 -0400, Jeffrey Haas wrote: > On Wed, Mar 12, 2014 at 06:26:19AM +0000, Mach Chen wrote: >> Thanks for the detail explanation, it's clear. >> >> According to your and Marc's response, seems that one system could >> choose to set the P bit (strictly as RFC5880 says) or clear the P >> bit (as you said and some implementations do). The key point is that >> the remote system could properly process the control packet >> with/without P bit set. >> >> Ask this question, because I saw two implementations that one set >> the P bit and the other does not. > > The place this is problematic is that the P-bit expects the F-bit to be > used. It can't be wholly ignored. But the procedure also means that if the > F-bit is received, the poll should end. This isn't a very good fit for the > usual state machine changes because multiple packets may be sent and > received as the state machine transitions. > > My recommendation would be that poll sequences (sec. 6.5) should only be > used for parameter changes outside of those part of the state machine > transitioning to the Up state. > > A reminder from section 6: > "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." > > -- Jeff > From nobody Wed Mar 12 10:42:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220971A078B for ; Wed, 12 Mar 2014 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWPXPrgWT0Mw for ; Wed, 12 Mar 2014 10:42:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B81F21A048E for ; Wed, 12 Mar 2014 10:41:59 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8FE97C345; Wed, 12 Mar 2014 13:41:53 -0400 (EDT) Date: Wed, 12 Mar 2014 13:41:53 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Question abouth P bit setting Message-ID: <20140312174153.GK29320@pfrc> References: <20140312141903.GI29320@pfrc> <20140312095541956142.a132bc06@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140312095541956142.a132bc06@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AMe8C5-FNMwXBzlJrz9tVRiyGqk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 17:42:19 -0000 Marc, On Wed, Mar 12, 2014 at 09:55:41AM -0700, Marc Binderberger wrote: > hmm, I'm a bit lost :-) as I don't see the problem. The Poll sequence - > sending P, receiving F - seems orthogonal to the state machine for me. > It's just a synchronization mechanism on top to ensure timers are set > in the right sequence. Agreed. It just means that the dance that occurs as the state machine is being moved becomes more complicated because you have to also worry about p and f bit state while it's happening. Just an extra complication. > If you mean "stay out of grey zones and don't make assumptions" then I > agree though :-) One could always bring the session to Up with slow > timers, then start P-F to change to fast timers. While certainly possible, I suspect it'd break a lot of people's desired behaviors for the protocol. In particular, don't let a state machine transition happen unless you can accommodate the desired timers. -- Jeff From nobody Wed Mar 12 12:27:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8471A077C for ; Wed, 12 Mar 2014 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjfaLP1upEVr for ; Wed, 12 Mar 2014 12:27:51 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C37DD1A0644 for ; Wed, 12 Mar 2014 12:27:50 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id l9so51888eaj.17 for ; Wed, 12 Mar 2014 12:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:content-type; bh=DsVmC3SI+yPnWRk2nSHnKc9BPvCe+tknw+BdQ37XHa8=; b=UCPvho0UAmv/VaNi3Y2AhkfXfMzw8afFjZGReDMi/4XSQ94/gi9IykQlUlYbjJYIro G97copSRYayQwFubSpcXF/wAlrpb7hkOaqk9T6aYF2Tc79fgV0wF12LRlZveyzTHVoWC KJdDXyIOQFXhBLAxY9099753GV7xIpnid6GyfJk3hKXBsAbILwBxP6JQPtYDMnT0ta9F HPhs0NSc7nztq3UzhjervYWuiug+KaCB09F+OL9Za4NccmzcdEHxu/Q9KC5bpeL81avl 2JA8UyqZvHgasAJWzaxc5KocMRMHmrQ26uOXw58w4ue49qJ4kyunJsacMaxisaXmgHKk eodw== X-Received: by 10.14.6.1 with SMTP id 1mr5604015eem.71.1394652464186; Wed, 12 Mar 2014 12:27:44 -0700 (PDT) Received: from [192.168.110.100] ([212.150.126.138]) by mx.google.com with ESMTPSA id x6sm73315235eew.20.2014.03.12.12.27.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Mar 2014 12:27:42 -0700 (PDT) Message-ID: <5320b52e.06380f0a.2a6e.63c8@mx.google.com> MIME-Version: 1.0 To: Marc Binderberger , Jeffrey Haas From: Binny Jeshan Subject: RE: Question abouth P bit setting Date: Wed, 12 Mar 2014 21:27:03 +0200 Content-Type: multipart/alternative; boundary="_116D1A7D-3E3B-4101-861F-E5ADFF0A6C9C_" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fjw_aE9_I-7Mx1pgNWlD42XYfww Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 19:27:53 -0000 --_116D1A7D-3E3B-4101-861F-E5ADFF0A6C9C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" "One could always bring the session to Up with slow=20 timers, then start P-F to change to fast timers." Hmmm, interesting. I don't see anything is wrong with this, though its anot= her extra step in the process, but sending P bit when moving to Down State = would be some extra piece of code to make things even more sophisticated. L= et the software Architect and the System Engg.. decide about it , such tha= t at least on deployment they don't get tickets raised over this method :D Regards, Binny. Aricent Group, India Sent from Nokia Lumia. -----Original Message----- From: "Marc Binderberger" Sent: =E2=80=8E12-=E2=80=8E03-=E2=80=8E2014 06:55 PM To: "Jeffrey Haas" Cc: "rtg-bfd@ietf.org" Subject: Re: Question abouth P bit setting Hello Jeff, hmm, I'm a bit lost :-) as I don't see the problem. The Poll sequence -=20 sending P, receiving F - seems orthogonal to the state machine for me.=20 It's just a synchronization mechanism on top to ensure timers are set=20 in the right sequence. If you mean "stay out of grey zones and don't make assumptions" then I=20 agree though :-) One could always bring the session to Up with slow=20 timers, then start P-F to change to fast timers. Regards, Marc On Wed, 12 Mar 2014 10:19:03 -0400, Jeffrey Haas wrote: > On Wed, Mar 12, 2014 at 06:26:19AM +0000, Mach Chen wrote: >> Thanks for the detail explanation, it's clear. >>=20 >> According to your and Marc's response, seems that one system could=20 >> choose to set the P bit (strictly as RFC5880 says) or clear the P=20 >> bit (as you said and some implementations do). The key point is that=20 >> the remote system could properly process the control packet=20 >> with/without P bit set. >>=20 >> Ask this question, because I saw two implementations that one set=20 >> the P bit and the other does not. >=20 > The place this is problematic is that the P-bit expects the F-bit to be > used. It can't be wholly ignored. But the procedure also means that if = the > F-bit is received, the poll should end. This isn't a very good fit for t= he > usual state machine changes because multiple packets may be sent and > received as the state machine transitions. >=20 > My recommendation would be that poll sequences (sec. 6.5) should only be > used for parameter changes outside of those part of the state machine > transitioning to the Up state. >=20 > A reminder from section 6: > "It is important for implementors to enforce only the requirements specif= ied > in this section, as misguided pedantry has been proven by experience to > affect interoperability adversely." >=20 > -- Jeff >=20 --_116D1A7D-3E3B-4101-861F-E5ADFF0A6C9C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
"One could = always bring the session to Up with slow
timers, then start P-F to chan= ge to fast timers."

Hmmm, interesting. I don't see anything is wrong= with this, though its another extra step in the process, but sending P bit= when moving to Down State would be some extra piece of code to make things= even more sophisticated. Let the software Architect and the System Engg..&= nbsp; decide about it , such that at least on deployment they don't get tic= kets raised over this method :D

Regards,
Binny.
Aricent Group,= India

Sent from Nokia Lumia.
From: Marc BinderbergerSent: =E2=80=8E12-=E2=80=8E03-=E2=80=8E2014 06:55 PM
To: Jeffrey Haas
Cc: rtg-bfd@ietf.org
Subject: Re: Question abouth P bit setting

Hello Jeff,<= BR>
hmm, I'm a bit lost :-) as I don't see the problem. The Poll sequenc= e -
sending P, receiving F - seems orthogonal to the state machine for = me.
It's just a synchronization mechanism on top to ensure timers are s= et
in the right sequence.

If you mean "stay out of grey zones an= d don't make assumptions" then I
agree though :-)  One could alway= s bring the session to Up with slow
timers, then start P-F to change to= fast timers.


Regards, Marc



On Wed, 12 Mar 2014 1= 0:19:03 -0400, Jeffrey Haas wrote:
> On Wed, Mar 12, 2014 at 06:26:19= AM +0000, Mach Chen wrote:
>> Thanks for the detail explanation, i= t's clear.
>>
>> According to your and Marc's response, = seems that one system could
>> choose to set the P bit (strictly = as RFC5880 says) or clear the P
>> bit (as you said and some impl= ementations do). The key point is that
>> the remote system could= properly process the control packet
>> with/without P bit set.>>
>> Ask this question, because I saw two implementation= s that one set
>> the P bit and the other does not.
>
&= gt; The place this is problematic is that the P-bit expects the F-bit to be=
> used.  It can't be wholly ignored.  But the procedure al= so means that if the
> F-bit is received, the poll should end.  = This isn't a very good fit for the
> usual state machine changes beca= use multiple packets may be sent and
> received as the state machine = transitions.
>
> My recommendation would be that poll sequence= s (sec. 6.5) should only be
> used for parameter changes outside of t= hose part of the state machine
> transitioning to the Up state.
&g= t;
> A reminder from section 6:
> "It is important for impleme= ntors to enforce only the requirements specified
> in this section, a= s misguided pedantry has been proven by experience to
> affect intero= perability adversely."
>
> -- Jeff
>

= --_116D1A7D-3E3B-4101-861F-E5ADFF0A6C9C_-- From nobody Wed Mar 12 19:11:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F081A069C for ; Wed, 12 Mar 2014 19:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYavNE64tQxZ for ; Wed, 12 Mar 2014 19:11:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 621411A06C1 for ; Wed, 12 Mar 2014 19:11:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCA09975; Thu, 13 Mar 2014 02:10:54 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Mar 2014 02:10:00 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Mar 2014 02:10:53 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 10:10:46 +0800 From: Mach Chen To: Jeffrey Haas , Marc Binderberger Subject: RE: Question abouth P bit setting Thread-Topic: Question abouth P bit setting Thread-Index: Ac88/5dFi5viacsrTWOzMz5Bed6N9P//nJeA//55C1CAA2EcgIAAK8SAgAAM6ID//uv3IA== Date: Thu, 13 Mar 2014 02:10:45 +0000 Message-ID: References: <20140312141903.GI29320@pfrc> <20140312095541956142.a132bc06@sniff.de> <20140312174153.GK29320@pfrc> In-Reply-To: <20140312174153.GK29320@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/TDe0Jw4sOWVSNn-O_J83WQcoets Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 02:11:05 -0000 Hi Jeff and Marc, >=20 > While certainly possible, I suspect it'd break a lot of people's desired = behaviors > for the protocol. In particular, don't let a state machine transition ha= ppen unless > you can accommodate the desired timers. Agree. Best regards, Mach >=20 > -- Jeff From nobody Thu Mar 13 11:27:37 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FDD1A058E for ; Thu, 13 Mar 2014 11:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEddhSjnFJ17 for ; Thu, 13 Mar 2014 11:27:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE6F1A0492 for ; Thu, 13 Mar 2014 11:27:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B20A0C552; Thu, 13 Mar 2014 14:27:27 -0400 (EDT) Date: Thu, 13 Mar 2014 14:27:27 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Possible addition to S-BFD use-case draft? Message-ID: <20140313182727.GM29320@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/W23zVPXkjxLgWO-qKvqN7YGp-J0 Cc: "Sam Aldrin \(sam.aldrin@gmail.com\)" , "satoru.matsushima@g.softbank.co.jp" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:27:36 -0000 Nobo, On Wed, Mar 05, 2014 at 04:06:07PM +0000, Nobo Akiya (nobo) wrote: > I'd like to propose a possible addition to the S-BFD use-case draft. > > BFD MPLS (RFC5884) states: > > [snip] > If there are multiple alternate paths from an ingress LSR to an > egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > determine each of these alternate paths. A BFD session SHOULD be > established for each alternate path that is discovered. > [snip] > > Above implies that a BFD session should be bootstrapped per alternate (i.e. ECMP) path, but RFC does not have further details no how to create/maintain multiple BFD MPLS sessions per FEC. Questions I have are: > * How should egress de-multiplex the bootstrap request per alternate path? > * If/when number of alternate paths changes or hash key changes: > - how should ingress delete BFD sessions on egress? > - re-bootstrapping set of sessions can be [relatively] inefficient as that can consume time/resources. > > Alternative is to use S-BFD for multiple alternate paths for a FEC, which eliminates the concerns raised from above questions ... and much simpler to implement and operate. My impression is that the alternate paths are known via MPLS traceroute and thus the BFD packet can have the appropriate label stack added. -- Jeff (not terribly clueful here) From nobody Thu Mar 13 11:34:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0291A0A41 for ; Thu, 13 Mar 2014 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpYOI5-kyZnH for ; Thu, 13 Mar 2014 11:34:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 44EFF1A0A33 for ; Thu, 13 Mar 2014 11:34:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7FD5DC382; Thu, 13 Mar 2014 14:24:32 -0400 (EDT) Date: Thu, 13 Mar 2014 14:24:32 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Message-ID: <20140313182432.GL29320@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140311165705373444.759ede3c@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ll2_Il7QqAcEjUxzE17wOKT3gRo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:34:30 -0000 On Tue, Mar 11, 2014 at 04:57:05PM -0700, Marc Binderberger wrote: > Hello Nobo et al., > > S-BFD draft can override the meaning of D-bit in the context of S-BFD > > only. We do not need to go back to RFC5880/RFC5881 and make changes. > > This is an interesting point: can we? > > Technically I like to have a flag to separate the "ping" from the > "pong". Simple logic. Redefining a packet definition, not "from here > on" but in parallel to the still valid RFC5880 seems somewhat odd to > me. Do we have examples in IETF for this? IMNSHO, D-bit behavior is a base feature of BFD v0/v1 as defined in the various specs. Making that behavior vary without a version number change may be pushing things a bit. FWIW, I thought we had a discussion about this particular issue off-list previously. The suggested semantic was P/F state to be used to prevent infinite looping. E.g. A---M---B M sends packet to A in current scenario spoofing B's address. We have loop in current proposal. If A required P to be set and always responded with F, B would receive F and drop the packet. -- Jeff From nobody Thu Mar 13 11:36:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6C11A071B for ; Thu, 13 Mar 2014 11:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMgUU_MJnIQF for ; Thu, 13 Mar 2014 11:36:02 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 209BB1A0645 for ; Thu, 13 Mar 2014 11:36:02 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B24E72AA0F; Thu, 13 Mar 2014 18:35:53 +0000 (GMT) Date: Thu, 13 Mar 2014 11:35:57 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140313113557056990.2cc36f2b@sniff.de> In-Reply-To: <20140313182432.GL29320@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ADCKgDAcVFCUZOSEd5QA8SN_1tk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:36:04 -0000 Hello Jeff, > If A required P to be set and always responded with F, B would receive F and > drop the packet. ah! Let me go back to RFC5880 and what it says about Ps and Fs but I think this sounds good. Right, this was mentioned before but I never understood why someone would want to go for a Poll sequence - now I know. Regards, Marc P.S.: IMNSHO ?!? In My Not So Humble Opinion? Or the new set of flags proposed for S-BFD? ;-) On Thu, 13 Mar 2014 14:24:32 -0400, Jeffrey Haas wrote: > On Tue, Mar 11, 2014 at 04:57:05PM -0700, Marc Binderberger wrote: >> Hello Nobo et al., >>> S-BFD draft can override the meaning of D-bit in the context of S-BFD >>> only. We do not need to go back to RFC5880/RFC5881 and make changes. >> >> This is an interesting point: can we? >> >> Technically I like to have a flag to separate the "ping" from the >> "pong". Simple logic. Redefining a packet definition, not "from here >> on" but in parallel to the still valid RFC5880 seems somewhat odd to >> me. Do we have examples in IETF for this? > > IMNSHO, D-bit behavior is a base feature of BFD v0/v1 as defined in the > various specs. Making that behavior vary without a version number change > may be pushing things a bit. > > FWIW, I thought we had a discussion about this particular issue off-list > previously. The suggested semantic was P/F state to be used to prevent > infinite looping. E.g. > > A---M---B > > M sends packet to A in current scenario spoofing B's address. We have loop > in current proposal. > > If A required P to be set and always responded with F, B would receive F and > drop the packet. > > -- Jeff > From nobody Thu Mar 13 11:39:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E931A07F5 for ; Thu, 13 Mar 2014 11:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8ghStMu8upV for ; Thu, 13 Mar 2014 11:39:06 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id D92ED1A0729 for ; Thu, 13 Mar 2014 11:39:05 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,648,1389762000"; d="scan'208,217";a="8553554" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 13 Mar 2014 14:38:59 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 14:38:58 -0400 From: "Snyder, Brian" To: "rtg-bfd@ietf.org" Subject: Question on DHCP Thread-Topic: Question on DHCP Thread-Index: Ac8+6wFhq4FgxhpPRcm0SiNKXk9ugQ== Date: Thu, 13 Mar 2014 18:38:32 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_84585478AABBBF4B9DF597FC0F84AF7342F39ADFVAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/3-UlLecUz18CQel60IqDusyZIqY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:39:08 -0000 --_000_84585478AABBBF4B9DF597FC0F84AF7342F39ADFVAUSMBX03idirec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all. I suspect the answer is NO, as I have seen no other mention of DHCP hooks i= n the RFC or configuration guides, but thougth I'd double check. If say the router was receiving it's WAN interface via DHCP, and then say O= SPF was peered, I know how BFD could shut down the OSPF peer if a link went= down in between. Is it possible or considered to hook up the receipt of t= he dynamic IP address to the BFD state as well? So if BFD control flow fai= led, one could trigger DHCP to try and reacquire an IP address on that inte= rface? If the answer is NO as I suggest, would this list have any potent= ial ideas on how to go about doing so (there are likely lots of router tri= cks I am unfamiliar with ;)). Regards, Brian --_000_84585478AABBBF4B9DF597FC0F84AF7342F39ADFVAUSMBX03idirec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all.

 

I suspect the answer is NO, as I have seen no other = mention of DHCP hooks in the RFC or configuration guides, but thougth IR= 17;d double check.

 

 

If say the router was receiving it’s WAN inter= face via DHCP, and then say OSPF was peered, I know how BFD could shut down= the OSPF peer if a link went down in between.  Is it possible or cons= idered to hook up the receipt of the dynamic IP address to the BFD state as well?  So if BFD control flow failed, = one could trigger DHCP to try and reacquire an IP address on that interface= ?    If the answer is NO as I suggest, would this list have = any potential ideas on how to go about doing so  (there are likely lots of router tricks I am unfamiliar with ;)).

 

Regards,

Brian

--_000_84585478AABBBF4B9DF597FC0F84AF7342F39ADFVAUSMBX03idirec_-- From nobody Thu Mar 13 11:49:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A61A0492 for ; Thu, 13 Mar 2014 11:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr5VsZ0vqB57 for ; Thu, 13 Mar 2014 11:49:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE481A08B5 for ; Thu, 13 Mar 2014 11:49:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1A606C382; Thu, 13 Mar 2014 14:49:36 -0400 (EDT) Date: Thu, 13 Mar 2014 14:49:36 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Message-ID: <20140313184936.GB18110@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140313113557056990.2cc36f2b@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Z281p1gjbnWPKeQFTZ60BkExNUA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:49:47 -0000 On Thu, Mar 13, 2014 at 11:35:57AM -0700, Marc Binderberger wrote: > Hello Jeff, > > > If A required P to be set and always responded with F, B would receive F and > > drop the packet. > > ah! Let me go back to RFC5880 and what it says about Ps and Fs but I > think this sounds good. > > Right, this was mentioned before but I never understood why someone > would want to go for a Poll sequence - now I know. There you have it. Just for the broader record, I believe it was Santosh PK who made the original observation. > P.S.: IMNSHO ?!? In My Not So Humble Opinion? Or the new set of flags > proposed for S-BFD? ;-) Ego flag bits particularly required for IETF WG chairs. :-) -- Jeff From nobody Thu Mar 13 11:51:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC00E1A0492 for ; Thu, 13 Mar 2014 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e2reDILzKlC for ; Thu, 13 Mar 2014 11:51:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B753A1A08D3 for ; Thu, 13 Mar 2014 11:51:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 58C9FC382; Thu, 13 Mar 2014 14:51:44 -0400 (EDT) Date: Thu, 13 Mar 2014 14:51:44 -0400 From: Jeffrey Haas To: "Snyder, Brian" Subject: Re: Question on DHCP Message-ID: <20140313185144.GC18110@pfrc> References: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/MwpZoMhAJYLHI5QB3NRewZ-zC1M Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:51:55 -0000 Brian, On Thu, Mar 13, 2014 at 06:38:32PM +0000, Snyder, Brian wrote: > I suspect the answer is NO, as I have seen no other mention of DHCP hooks in the RFC or configuration guides, but thougth I'd double check. > > > If say the router was receiving it's WAN interface via DHCP, and then say OSPF was peered, I know how BFD could shut down the OSPF peer if a link went down in between. Is it possible or considered to hook up the receipt of the dynamic IP address to the BFD state as well? So if BFD control flow failed, one could trigger DHCP to try and reacquire an IP address on that interface? If the answer is NO as I suggest, would this list have any potential ideas on how to go about doing so (there are likely lots of router tricks I am unfamiliar with ;)). At one point, support for DHCP was a WG chartered item. However, work never proceeded on it. There's no reason why CPE couldn't establish a low-speed BFD session with the BNG for the purpose you're wanting. I'm not sure any specific standardization requirements are necessary, unless the goal is to seed BFD Discriminator values for such sessions as part of DHCP handshake. -- Jeff From nobody Thu Mar 13 11:54:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3721A0492 for ; Thu, 13 Mar 2014 11:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBsTEDA5EKy4 for ; Thu, 13 Mar 2014 11:53:59 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id CCCCB1A08B5 for ; Thu, 13 Mar 2014 11:53:58 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,648,1389762000"; d="scan'208";a="1065129" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 13 Mar 2014 14:53:51 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 14:53:51 -0400 From: "Snyder, Brian" To: Jeffrey Haas Subject: RE: Question on DHCP Thread-Topic: Question on DHCP Thread-Index: Ac8+6wFhq4FgxhpPRcm0SiNKXk9ugQAI8zkAAAhczDA= Date: Thu, 13 Mar 2014 18:53:25 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342F39B42@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> <20140313185144.GC18110@pfrc> In-Reply-To: <20140313185144.GC18110@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/f-efildZbhMSPEnH259lw6os5DQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:54:00 -0000 Sure. We could do it ourselves in our code, but if big guys like Cisco or J= uniper don't support this, then we can only go so far on our own ;) If I u= nderstand your message correctly , no standardization of this functionality= has occurred - so likely no one supports it. Correct? Forgive my ignorance, I'm kinda new to talking on these types of groups, bu= t how would one go about getting this 'back on the docket' so to speak? Thanks, brian -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Thursday, March 13, 2014 2:52 PM To: Snyder, Brian Cc: rtg-bfd@ietf.org Subject: Re: Question on DHCP Brian, On Thu, Mar 13, 2014 at 06:38:32PM +0000, Snyder, Brian wrote: > I suspect the answer is NO, as I have seen no other mention of DHCP hooks= in the RFC or configuration guides, but thougth I'd double check. >=20 >=20 > If say the router was receiving it's WAN interface via DHCP, and then say= OSPF was peered, I know how BFD could shut down the OSPF peer if a link we= nt down in between. Is it possible or considered to hook up the receipt of= the dynamic IP address to the BFD state as well? So if BFD control flow f= ailed, one could trigger DHCP to try and reacquire an IP address on that in= terface? If the answer is NO as I suggest, would this list have any pote= ntial ideas on how to go about doing so (there are likely lots of router t= ricks I am unfamiliar with ;)). At one point, support for DHCP was a WG chartered item. However, work neve= r proceeded on it. There's no reason why CPE couldn't establish a low-speed BFD session with t= he BNG for the purpose you're wanting. I'm not sure any specific standardi= zation requirements are necessary, unless the goal is to seed BFD Discrimin= ator values for such sessions as part of DHCP handshake. -- Jeff From nobody Thu Mar 13 11:55:01 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0851A0492 for ; Thu, 13 Mar 2014 11:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dY_z1B8vat5 for ; Thu, 13 Mar 2014 11:54:59 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E861A0729 for ; Thu, 13 Mar 2014 11:54:58 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 1CF092AA0F; Thu, 13 Mar 2014 18:54:50 +0000 (GMT) Date: Thu, 13 Mar 2014 11:54:54 -0700 From: Marc Binderberger To: "Snyder, Brian" Message-ID: <20140313115454472086.53ae8ed2@sniff.de> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> Subject: Re: Question on DHCP MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/w2b_Xkkzk-NurbHW4uKOg8clQcA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:55:00 -0000 SGVsbG8gQnJpYW4sDQoNCmRvbid0IHRoaW5rIHRoaXMgaXMgYSBwcm9ibGVtIHRvIGJlIHNv bHZlZCB3aXRoaW4gdGhlIEJGRCBwcm90b2NvbCAtIA0Kd2hpY2ggdGhpcyBsaXN0IGlzIGZv ci4gU291bmRzIG1vcmUgbGlrZSBhIHJvdXRlci1zcGVjaWZpYyBxdWVzdGlvbi4NCg0KRGlm ZmljdWx0IHRvIG1ha2Ugc3RhdGVtZW50cyBhYm91dCB3aGF0IHJvdXRlcnMgY2FuIGRvIC0g aXQncyANCmltcGxlbWVudGF0aW9uIHNwZWNpZmljLCBkZXRhaWxzIGFyZSB1c3VhbGx5IGNs b3NlZCBhbmQgcHJvcHJpZXRhcnkuIA0KR2VuZXJhbGx5IHNwZWFraW5nOiB0aGUgIkJGRCBw cm9jZXNzIiBjb3VsZCBpbXBsZW1lbnQgYW4gQVBJIHRvIGluZm9ybSANCndoZW4gYSBwYXJ0 aWN1bGFyIHNlc3Npb24gY2hhbmdlcyBzdGF0ZS4gSW4geW91ciBjYXNlIHRoZSAiREhDUCAN CnByb2Nlc3MiIGNvdWxkIHVzZSBzdWNoIGFuIEFQSSB0byBsZWFybiBhYm91dCB0aGUgQkZE IHNlc3Npb24gb24gdGhlIA0KaW50ZXJmYWNlIGdvaW5nIGRvd24uDQoNCkFnYWluLCB0aGlz IGlzIGFuIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFzcGVjdCwgbm90IHJlbGF0ZWQgdG8g dGhlIA0KQkZEIHByb3RvY29sIGl0c2VsZi4NCg0KDQpSZWdhcmRzLCBNYXJjDQoNCg0KDQpP biBUaHUsIDEzIE1hciAyMDE0IDE4OjM4OjMyICswMDAwLCBTbnlkZXIsIEJyaWFuIHdyb3Rl Og0KPiBIaSBhbGwuDQo+ICANCj4gSSBzdXNwZWN0IHRoZSBhbnN3ZXIgaXMgTk8sIGFzIEkg aGF2ZSBzZWVuIG5vIG90aGVyIG1lbnRpb24gb2YgREhDUCANCj4gaG9va3MgaW4gdGhlIFJG QyBvciBjb25maWd1cmF0aW9uIGd1aWRlcywgYnV0IHRob3VndGggSaJkIGRvdWJsZSANCj4g Y2hlY2suDQo+ICANCj4gIA0KPiBJZiBzYXkgdGhlIHJvdXRlciB3YXMgcmVjZWl2aW5nIGl0 onMgV0FOIGludGVyZmFjZSB2aWEgREhDUCwgYW5kIHRoZW4gDQo+IHNheSBPU1BGIHdhcyBw ZWVyZWQsIEkga25vdyBob3cgQkZEIGNvdWxkIHNodXQgZG93biB0aGUgT1NQRiBwZWVyIGlm IA0KPiBhIGxpbmsgd2VudCBkb3duIGluIGJldHdlZW4uICBJcyBpdCBwb3NzaWJsZSBvciBj b25zaWRlcmVkIHRvIGhvb2sgdXAgDQo+IHRoZSByZWNlaXB0IG9mIHRoZSBkeW5hbWljIElQ IGFkZHJlc3MgdG8gdGhlIEJGRCBzdGF0ZSBhcyB3ZWxsPyAgU28gDQo+IGlmIEJGRCBjb250 cm9sIGZsb3cgZmFpbGVkLCBvbmUgY291bGQgdHJpZ2dlciBESENQIHRvIHRyeSBhbmQgDQo+ IHJlYWNxdWlyZSBhbiBJUCBhZGRyZXNzIG9uIHRoYXQgaW50ZXJmYWNlPyAgICBJZiB0aGUg YW5zd2VyIGlzIE5PIGFzIA0KPiBJIHN1Z2dlc3QsIHdvdWxkIHRoaXMgbGlzdCBoYXZlIGFu eSBwb3RlbnRpYWwgaWRlYXMgb24gaG93IHRvIGdvIA0KPiBhYm91dCBkb2luZyBzbyAgKHRo ZXJlIGFyZSBsaWtlbHkgbG90cyBvZiByb3V0ZXIgdHJpY2tzIEkgYW0gDQo+IHVuZmFtaWxp YXIgd2l0aCA7KSkuDQo+ICANCj4gUmVnYXJkcywNCj4gQnJpYW4= From nobody Thu Mar 13 11:57:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D511A02E6 for ; Thu, 13 Mar 2014 11:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1obgoComEpfc for ; Thu, 13 Mar 2014 11:57:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 296041A0155 for ; Thu, 13 Mar 2014 11:57:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AB709C382; Thu, 13 Mar 2014 14:57:42 -0400 (EDT) Date: Thu, 13 Mar 2014 14:57:42 -0400 From: Jeffrey Haas To: "Snyder, Brian" Subject: Re: Question on DHCP Message-ID: <20140313185742.GD18110@pfrc> References: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> <20140313185144.GC18110@pfrc> <84585478AABBBF4B9DF597FC0F84AF7342F39B42@VAUS-MBX03.idirect.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342F39B42@VAUS-MBX03.idirect.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/yWkDGSz2Yof8Gq_0fkCbZjS7kBw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 18:57:50 -0000 On Thu, Mar 13, 2014 at 06:53:25PM +0000, Snyder, Brian wrote: > Sure. We could do it ourselves in our code, but if big guys like Cisco or Juniper don't support this, then we can only go so far on our own ;) If I understand your message correctly , no standardization of this functionality has occurred - so likely no one supports it. Correct? The fact that there was previously a WG item suggested that someone was interested in it, but no standardization happened in BFD. As I said, this is mostly a matter of simply using standard BFD with the potential case of an interesting bootstrap scenario - and that may be not necessary. Since the necessary standardization hooks are either unnecessary or very low and within scope of the existing protocol, we may not know about them. > Forgive my ignorance, I'm kinda new to talking on these types of groups, but how would one go about getting this 'back on the docket' so to speak? BFD and DHCP are standardized in IETF. The use cases you're concerned with may be getting standardized in other bodies such as the Broadband Forum. I'm not active in that organization and don't have a helpful pointer. Sorry. -- Jeff From nobody Thu Mar 13 12:24:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE2C1A09D8 for ; Thu, 13 Mar 2014 12:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xVRkhP6li_N for ; Thu, 13 Mar 2014 12:24:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 86F751A09AB for ; Thu, 13 Mar 2014 12:24:03 -0700 (PDT) Received: from mail78-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Mar 2014 19:23:56 +0000 Received: from mail78-ch1 (localhost [127.0.0.1]) by mail78-ch1-R.bigfish.com (Postfix) with ESMTP id 955E2140129; Thu, 13 Mar 2014 19:23:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh9a9j1155h) Received-SPF: pass (mail78-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=santoshpk@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(189002)(51704005)(24454002)(13464003)(81686001)(95666003)(87936001)(74316001)(80976001)(33646001)(51856001)(81816001)(76796001)(56816005)(76786001)(87266001)(76576001)(83322001)(19580395003)(19580405001)(83072002)(2656002)(86362001)(85852003)(90146001)(97186001)(56776001)(94316002)(94946001)(97336001)(46102001)(93136001)(95416001)(54356001)(77982001)(81542001)(81342001)(59766001)(74876001)(79102001)(49866001)(74706001)(53806001)(85306002)(31966008)(66066001)(74662001)(65816001)(69226001)(76482001)(74502001)(47976001)(92566001)(50986001)(63696002)(80022001)(93516002)(74366001)(4396001)(47736001)(47446002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB946; H:BLUPR05MB755.namprd05.prod.outlook.com; CLIP:116.197.184.10; FPR:94F7F022.B7C25FC5.7EE7BFCB.EC9A00.202D3; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail78-ch1 (localhost.localdomain [127.0.0.1]) by mail78-ch1 (MessageSwitch) id 1394738635684147_8974; Thu, 13 Mar 2014 19:23:55 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail78-ch1.bigfish.com (Postfix) with ESMTP id 913E54A0053; Thu, 13 Mar 2014 19:23:55 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Mar 2014 19:23:53 +0000 Received: from BLUPR05MB946.namprd05.prod.outlook.com (10.141.204.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 13 Mar 2014 19:23:51 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB946.namprd05.prod.outlook.com (10.141.204.152) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 13 Mar 2014 19:23:50 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.0888.003; Thu, 13 Mar 2014 19:23:50 +0000 From: Santosh P K To: Jeffrey Haas , "Snyder, Brian" Subject: RE: Question on DHCP Thread-Topic: Question on DHCP Thread-Index: Ac8+6wFhq4FgxhpPRcm0SiNKXk9ugQAAkXUAAAAPDYAAACZMAAAA283Q Date: Thu, 13 Mar 2014 19:23:49 +0000 Message-ID: <8e5bfefc342f404f9927c1daee7f44e2@BLUPR05MB755.namprd05.prod.outlook.com> References: <84585478AABBBF4B9DF597FC0F84AF7342F39ADF@VAUS-MBX03.idirect.net> <20140313185144.GC18110@pfrc> <84585478AABBBF4B9DF597FC0F84AF7342F39B42@VAUS-MBX03.idirect.net> <20140313185742.GD18110@pfrc> In-Reply-To: <20140313185742.GD18110@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-forefront-prvs: 01494FA7F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qZT-JWC40sw7IZFYh6oh4r_Cfjs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 19:24:06 -0000 Hello Brain, WT-146 broadband document recommends use of BFD for DHCP.=20 Thanks Santos P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Friday, March 14, 2014 12:28 AM > To: Snyder, Brian > Cc: rtg-bfd@ietf.org > Subject: Re: Question on DHCP >=20 > On Thu, Mar 13, 2014 at 06:53:25PM +0000, Snyder, Brian wrote: > > Sure. We could do it ourselves in our code, but if big guys like Cisco = or Juniper > don't support this, then we can only go so far on our own ;) If I unders= tand your > message correctly , no standardization of this functionality has occurred= - so > likely no one supports it. Correct? >=20 > The fact that there was previously a WG item suggested that someone was > interested in it, but no standardization happened in BFD. As I said, thi= s is mostly > a matter of simply using standard BFD with the potential case of an inter= esting > bootstrap scenario - and that may be not necessary. >=20 > Since the necessary standardization hooks are either unnecessary or very = low > and within scope of the existing protocol, we may not know about them. >=20 > > Forgive my ignorance, I'm kinda new to talking on these types of groups= , but > how would one go about getting this 'back on the docket' so to speak? >=20 > BFD and DHCP are standardized in IETF. The use cases you're concerned wi= th > may be getting standardized in other bodies such as the Broadband Forum. > I'm not active in that organization and don't have a helpful pointer. > Sorry. >=20 > -- Jeff >=20 >=20 From nobody Thu Mar 13 12:59:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D001A0A46 for ; Thu, 13 Mar 2014 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh3eVhceQmFP for ; Thu, 13 Mar 2014 12:59:55 -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 796D11A0A40 for ; Thu, 13 Mar 2014 12:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2892; q=dns/txt; s=iport; t=1394740782; x=1395950382; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sv2E/m3djMXT5xMBcZXWkAn72x7j9sLw3cdV71SYYGM=; b=UnSbD9WUAeHCKgR2DLdCkMRpKjuvEHoclxttHkzUWy9n9xbInOBEHGyD I2ROu5kH1kM3Qaj7BbPilfbrLPITzzCM55kwcSw2L7aNRLouIP/5lLJMe k0Gkr7fvjrbS8sg1IyKTMirPGJVYbpKoqGLxaQY4NI/mJkpshOfV4woJN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAOwMIlOtJV2a/2dsb2JhbABZgmUhgRLBZIEdFnSCJQEBAQMBOj8FBwQCAQgOAwQBAQEKFAkHMhQJCAIEAQ0FCIdpCAHUIxeODAEBHjEHBoMegRQBA6pygy2Bcjk X-IronPort-AV: E=Sophos;i="4.97,648,1389744000"; d="scan'208";a="307119296" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 13 Mar 2014 19:59:41 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2DJxfrr030656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 19:59:41 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 14:59:41 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhA= Date: Thu, 13 Mar 2014 19:59:40 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> In-Reply-To: <20140313184936.GB18110@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KXA_rpmJpNuqYfcvEUqXF6IZW1w Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 19:59:57 -0000 Hi Jeff, Marc, et al, Had to go dig in my old mail box to find the reason for tossing the P/F ide= a. When a reflector session is receiving too many BFD control packets, we prop= osed two ways which reflector session can handle this. draft-akiya-bfd-seamless-base-02, sec 8.8 To do first bullet of above section, we need to preserve a way for reflecto= r session to tell initiators to "slow down" (i.e. update Required Min RX In= terval w/ P bit set). Reflector, w/o having state, won't be able to tell wh= ether initiators have honored the request, but it's a best effort way to "m= ake room for more initiators speaking to it".=20 > There you have it. Just for the broader record, I believe it was Santosh= PK > who made the original observation. Funny thing is, it was also Santosh PK who pointed out that P/F can't be us= ed if we want to preserve this ability. So we could keep P/F as originally proposed but remove the first bullet fro= m sec 8.8 of s-bfd-base-02 ... that's one way to go. > IMNSHO, D-bit behavior is a base feature of BFD v0/v1 as defined in the > various specs. Making that behavior vary without a version number change > may be pushing things a bit. Alright, noted. I'm still hoping that we can converge on a route which we d= o not have to bump up BFD version number (Pandora's box?), as that'll likel= y add significant delay before vendors can start the implementation. Another lesser-of-evils idea ... How about initiator MUST set both P and F, and reflector MUST clear [at lea= st] F? Packets with both P/F set will be considered invalid by any non-S-BF= D-reflector-sessions. Technically (fine line here) we don't have to change = the definition of the bits for S-BFD, but we only have to update procedures= and what is/isn't allowed by S-BFD. =09 -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, March 13, 2014 2:50 PM > To: Marc Binderberger > Cc: Jeffrey Haas; Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > On Thu, Mar 13, 2014 at 11:35:57AM -0700, Marc Binderberger wrote: > > Hello Jeff, > > > > > If A required P to be set and always responded with F, B would > > > receive F and drop the packet. > > > > ah! Let me go back to RFC5880 and what it says about Ps and Fs but I > > think this sounds good. > > > > Right, this was mentioned before but I never understood why someone > > would want to go for a Poll sequence - now I know. >=20 > There you have it. Just for the broader record, I believe it was Santosh= PK > who made the original observation. >=20 > > P.S.: IMNSHO ?!? In My Not So Humble Opinion? Or the new set of flags > > proposed for S-BFD? ;-) >=20 > Ego flag bits particularly required for IETF WG chairs. :-) >=20 > -- Jeff From nobody Thu Mar 13 13:09:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7AC1A0A48 for ; Thu, 13 Mar 2014 13:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwGzd954oOL0 for ; Thu, 13 Mar 2014 13:09:40 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D1F891A075C for ; Thu, 13 Mar 2014 13:09:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2DC25C137; Thu, 13 Mar 2014 16:09:27 -0400 (EDT) Date: Thu, 13 Mar 2014 16:09:27 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Message-ID: <20140313200927.GF18110@pfrc> References: <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xaYAX8u2eq9shOuToYu1TIR7fvU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 20:09:42 -0000 On Thu, Mar 13, 2014 at 07:59:40PM +0000, Nobo Akiya (nobo) wrote: > Had to go dig in my old mail box to find the reason for tossing the P/F idea. > > When a reflector session is receiving too many BFD control packets, we proposed two ways which reflector session can handle this. > > draft-akiya-bfd-seamless-base-02, sec 8.8 > > To do first bullet of above section, we need to preserve a way for reflector session to tell initiators to "slow down" (i.e. update Required Min RX Interval w/ P bit set). Reflector, w/o having state, won't be able to tell whether initiators have honored the request, but it's a best effort way to "make room for more initiators speaking to it". > > > There you have it. Just for the broader record, I believe it was Santosh PK > > who made the original observation. > > Funny thing is, it was also Santosh PK who pointed out that P/F can't be used if we want to preserve this ability. > > So we could keep P/F as originally proposed but remove the first bullet from sec 8.8 of s-bfd-base-02 ... that's one way to go. I may be mis-remembering the conversation or mis-reading the document, but since the reflector is intended to be stateless why would it expect to receive a Final from the Initiator? > How about initiator MUST set both P and F, and reflector MUST clear [at least] F? Packets with both P/F set will be considered invalid by any non-S-BFD-reflector-sessions. Technically (fine line here) we don't have to change the definition of the bits for S-BFD, but we only have to update procedures and what is/isn't allowed by S-BFD. Another bit from 5880: : Poll bit cleared. A BFD Control packet MUST NOT have both the Poll : (P) and Final (F) bits set. -- Jeff From nobody Thu Mar 13 13:12:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F5C1A0763 for ; Thu, 13 Mar 2014 13:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.952 X-Spam-Level: **** X-Spam-Status: No, score=4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, URIBL_SBL=20, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc9KBo7TLiDM for ; Thu, 13 Mar 2014 13:12:44 -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 4A7701A075C for ; Thu, 13 Mar 2014 13:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1394741558; x=1395951158; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cX0To5NgCNexbI0T8y1Kp3Vi0ktIGG6gc6CtoRkqCCc=; b=Jrhsj6xHBZBTNnXIufWkEIwzxYMEf1/fh9LMs08WnH9h8Pg44F3BEsDf XIYJcXVp0WFvWUqHhymaVxL1c3II8eSjyE/DwMJCzYMqrzz4+qGUT+f/f ARAc78uIKrkDyhoIrvOlG4VcysBPyAeU8Ewwj1pyW1V/cZjeSKlui0A+u Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKUQIlOtJV2c/2dsb2JhbABZgmUhgRLBZIEdFnSCJQEBAQQ6PwwEAgEIDgMEAQEBChQJByERFAkIAQEEDgUIh10DEQHMcA2HHxeMRoFmMQcGgx6BFAEDlliOUoVIgy2CKw X-IronPort-AV: E=Sophos;i="4.97,648,1389744000"; d="scan'208";a="310178899" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 13 Mar 2014 20:12:37 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2DKCbdN003971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 20:12:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 15:12:37 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: Possible addition to S-BFD use-case draft? Thread-Topic: Possible addition to S-BFD use-case draft? Thread-Index: Ac84hmdERRnvRqtWQuCLjKvrLSpA0QGjWRaAAAciN2A= Date: Thu, 13 Mar 2014 20:12:35 +0000 Message-ID: References: <20140313182727.GM29320@pfrc> In-Reply-To: <20140313182727.GM29320@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Q0dy58NjLBskvk1PSt3uVw63veM Cc: "Sam Aldrin \(sam.aldrin@gmail.com\)" , "satoru.matsushima@g.softbank.co.jp" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 20:12:46 -0000 Hi Jeff, > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, March 13, 2014 2:27 PM > To: Nobo Akiya (nobo) > Cc: Sam Aldrin (sam.aldrin@gmail.com); Bhatia, Manav (Manav) > (manav.bhatia@alcatel-lucent.com); Gregory Mirsky > (gregory.mirsky@ericsson.com); Nagendra Kumar Nainar (naikumar); > satoru.matsushima@g.softbank.co.jp; rtg-bfd@ietf.org > Subject: Re: Possible addition to S-BFD use-case draft? >=20 > Nobo, >=20 > On Wed, Mar 05, 2014 at 04:06:07PM +0000, Nobo Akiya (nobo) wrote: > > I'd like to propose a possible addition to the S-BFD use-case draft. > > > > BFD MPLS (RFC5884) states: > > > > [snip] > > If there are multiple alternate paths from an ingress LSR to an > > egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > > determine each of these alternate paths. A BFD session SHOULD be > > established for each alternate path that is discovered. > > [snip] > > > > Above implies that a BFD session should be bootstrapped per alternate > (i.e. ECMP) path, but RFC does not have further details no how to > create/maintain multiple BFD MPLS sessions per FEC. Questions I have are: > > * How should egress de-multiplex the bootstrap request per alternate > path? > > * If/when number of alternate paths changes or hash key changes: > > - how should ingress delete BFD sessions on egress? > > - re-bootstrapping set of sessions can be [relatively] inefficient = as that > can consume time/resources. > > > > Alternative is to use S-BFD for multiple alternate paths for a FEC, whi= ch > eliminates the concerns raised from above questions ... and much simpler > to implement and operate. >=20 > My impression is that the alternate paths are known via MPLS traceroute > and thus the BFD packet can have the appropriate label stack added. Yes, known via MPLS traceroute. Say this produces 8 ECMP paths. How do you = bootstrap (and maintain) 8 BFD over MPLS sessions on this LSP? -Nobo >=20 > -- Jeff (not terribly clueful here) From nobody Thu Mar 13 13:17:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B791A09E0 for ; Thu, 13 Mar 2014 13:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nDpFz1jS_Ld for ; Thu, 13 Mar 2014 13:17:32 -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 7890F1A075C for ; Thu, 13 Mar 2014 13:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2474; q=dns/txt; s=iport; t=1394741845; x=1395951445; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gsr1E1/9GHuDW/FLNeiSdQ5XC+RoSfQy3pT6DROkttY=; b=ilvbw1W8j3QUvRvCCOECCiQo2c4ncwpuoa/4kfnIeTB7NemEwBoL7shK 4uwP4jRgoBBd0wf8RaWpZ4p0rmaJ2a4cEZi68UsR74JKTmk6zYQkNO6nk wlPQhhJvLLS9DY39OvKwqXGPBWBkjv2WJBGGa0KogS2sWjCDPVGGlbBG1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFABwRIlOtJV2b/2dsb2JhbABZgmUhgRLBZIEdFnSCJQEBAQMBOj8MBAIBCA4DBAEBAQoUCQcyFAkIAgQOBQiHaQgB1BwXjgwBAR4xBwaDHoEUAQOqcoMtgXI5 X-IronPort-AV: E=Sophos;i="4.97,648,1389744000"; d="scan'208";a="310131082" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2014 20:17:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2DKHOS2011645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 20:17:24 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.03.0123.003; Thu, 13 Mar 2014 15:17:24 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyA Date: Thu, 13 Mar 2014 20:17:22 +0000 Message-ID: References: <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> <20140313200927.GF18110@pfrc> In-Reply-To: <20140313200927.GF18110@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/rXGtlrzgf5dDD2auUz83duFHiZ8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 20:17:34 -0000 Hi Jeff, > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, March 13, 2014 4:09 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > On Thu, Mar 13, 2014 at 07:59:40PM +0000, Nobo Akiya (nobo) wrote: > > Had to go dig in my old mail box to find the reason for tossing the P/F= idea. > > > > When a reflector session is receiving too many BFD control packets, we > proposed two ways which reflector session can handle this. > > > > draft-akiya-bfd-seamless-base-02, sec 8.8 > > > > To do first bullet of above section, we need to preserve a way for refl= ector > session to tell initiators to "slow down" (i.e. update Required Min RX > Interval w/ P bit set). Reflector, w/o having state, won't be able to tel= l > whether initiators have honored the request, but it's a best effort way t= o > "make room for more initiators speaking to it". > > > > > There you have it. Just for the broader record, I believe it was > > > Santosh PK who made the original observation. > > > > Funny thing is, it was also Santosh PK who pointed out that P/F can't b= e > used if we want to preserve this ability. > > > > So we could keep P/F as originally proposed but remove the first bullet > from sec 8.8 of s-bfd-base-02 ... that's one way to go. >=20 > I may be mis-remembering the conversation or mis-reading the document, > but since the reflector is intended to be stateless why would it expect t= o > receive a Final from the Initiator? It doesn't, reflector doesn't expect F bit (hence best effort). P bit will = alert initiator that parameter has changed (i.e. Required Min RX Interval h= as changed). >=20 > > How about initiator MUST set both P and F, and reflector MUST clear [at > least] F? Packets with both P/F set will be considered invalid by any non= -S- > BFD-reflector-sessions. Technically (fine line here) we don't have to cha= nge > the definition of the bits for S-BFD, but we only have to update procedur= es > and what is/isn't allowed by S-BFD. >=20 > Another bit from 5880: >=20 > : Poll bit cleared. A BFD Control packet MUST NOT have both the Poll > : (P) and Final (F) bits set. Yes that sentence is exactly what I thought of using both P/F. That paragra= ph can be "updated" by S-BFD base for S-BFD context. -Nobo >=20 > -- Jeff From nobody Thu Mar 13 13:27:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048A41A0473 for ; Thu, 13 Mar 2014 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Tq_Vklo9ePH for ; Thu, 13 Mar 2014 13:27:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7458B1A0A41 for ; Thu, 13 Mar 2014 13:27:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0437AC137; Thu, 13 Mar 2014 16:27:44 -0400 (EDT) Date: Thu, 13 Mar 2014 16:27:43 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Message-ID: <20140313202743.GG18110@pfrc> References: <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> <20140313200927.GF18110@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zvCCa9qok555Ru_5q4cVEkn7rpw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 20:27:54 -0000 On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: > > I may be mis-remembering the conversation or mis-reading the document, > > but since the reflector is intended to be stateless why would it expect to > > receive a Final from the Initiator? > > It doesn't, reflector doesn't expect F bit (hence best effort). P bit will alert initiator that parameter has changed (i.e. Required Min RX Interval has changed). Remember that the primary reason for the Required Min RX Interval in regular BFD is that the receiver is also running a timer and will use that for its state by helping to adjust the sender's speed in a graceful fashion. In this case, graceful is important since only the Initiator cares about the actual timing of the packets. And even then, for our original scenario: A---M---B As long as each side doesn't respond to F packets (but sends them), I think we're still good. I think this means you can keep the poll bit idea to help suggest an Initiator to slow down and still prevent DoS. In such a scenario, M is injecting packets to A, with or without P, using B's addressing. Without P, A could still respond with F and B would drop it. So, I suppose the suggested addition to the S-BFD logic is "in the absence of a P-bit, F will still be set for security purposes upon reflection." If a reflector wants to tell an Initiator to slow down, it would simply need to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. -- Jeff From nobody Thu Mar 13 13:30:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A971A0A10 for ; Thu, 13 Mar 2014 13:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ck6hoV432Bd for ; Thu, 13 Mar 2014 13:30:07 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4F91A09E0 for ; Thu, 13 Mar 2014 13:30:06 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 459CB2AA0F; Thu, 13 Mar 2014 20:29:58 +0000 (GMT) Date: Thu, 13 Mar 2014 13:30:01 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140313133001383691.d306e5f6@sniff.de> In-Reply-To: References: <7347100B5761DC41A166AC17F22DF1121B7784F0@eusaamb103.ericsson.se> <62bf7f7ba35440ce9d033de180f776c4@BLUPR05MB755.namprd05.prod.outlook.com> <20211F91F544D247976D84C5D778A4C32E5A7AA8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/emCa946IsCixNqWowBszC10WGek Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 20:30:08 -0000 Hello Nobo et al., > When a reflector session is receiving too many BFD control packets, > we proposed two ways which reflector session can handle this. > > draft-akiya-bfd-seamless-base-02, sec 8.8 > > To do first bullet of above section, we need to preserve a way for > reflector session to tell initiators to "slow down" (i.e. update > Required Min RX Interval w/ P bit set). Reflector, w/o having state, > won't be able to tell whether initiators have honored the request, > but it's a best effort way to "make room for more initiators speaking > to it". ah well, we simply don't have enough flags in the BFD packet. You are sure we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) But seriously: as the S-BFD sender is effectively talking to itself you do not need P/F to synchronize two systems. The reflector can simply set the Required Min RX Interval as it wants and the S-BFD sender adjusts. Also: as Jeff mentioned, without any "session state" on the reflector side it would be difficult to match any received F bit to a particular P sent out? Nevertheless, it would require we "overwrite" the statement in RFC5880 that any parameter change requires a Poll sequence. Not sure if we are any further then (?). But without state the Poll sequence doesn't seem applicable anyway, so ... . Regards, Marc > >> There you have it. Just for the broader record, I believe it was >> Santosh PK >> who made the original observation. > > Funny thing is, it was also Santosh PK who pointed out that P/F can't > be used if we want to preserve this ability. > > So we could keep P/F as originally proposed but remove the first > bullet from sec 8.8 of s-bfd-base-02 ... that's one way to go. > >> IMNSHO, D-bit behavior is a base feature of BFD v0/v1 as defined in the >> various specs. Making that behavior vary without a version number change >> may be pushing things a bit. > > Alright, noted. I'm still hoping that we can converge on a route > which we do not have to bump up BFD version number (Pandora's box?), > as that'll likely add significant delay before vendors can start the > implementation. > > Another lesser-of-evils idea ... > > How about initiator MUST set both P and F, and reflector MUST clear > [at least] F? Packets with both P/F set will be considered invalid by > any non-S-BFD-reflector-sessions. Technically (fine line here) we > don't have to change the definition of the bits for S-BFD, but we > only have to update procedures and what is/isn't allowed by S-BFD. > > -Nobo > >> -----Original Message----- >> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >> Sent: Thursday, March 13, 2014 2:50 PM >> To: Marc Binderberger >> Cc: Jeffrey Haas; Nobo Akiya (nobo); rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> On Thu, Mar 13, 2014 at 11:35:57AM -0700, Marc Binderberger wrote: >>> Hello Jeff, >>> >>>> If A required P to be set and always responded with F, B would >>>> receive F and drop the packet. >>> >>> ah! Let me go back to RFC5880 and what it says about Ps and Fs but I >>> think this sounds good. >>> >>> Right, this was mentioned before but I never understood why someone >>> would want to go for a Poll sequence - now I know. >> >> There you have it. Just for the broader record, I believe it was >> Santosh PK >> who made the original observation. >> >>> P.S.: IMNSHO ?!? In My Not So Humble Opinion? Or the new set of flags >>> proposed for S-BFD? ;-) >> >> Ego flag bits particularly required for IETF WG chairs. :-) >> >> -- Jeff > From nobody Thu Mar 13 13:48:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C6C1A0A19 for ; Thu, 13 Mar 2014 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9hL6aSP4RKN for ; Thu, 13 Mar 2014 13:48:35 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 246B31A075C for ; Thu, 13 Mar 2014 13:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3700; q=dns/txt; s=iport; t=1394743708; x=1395953308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UDx25fv7SrZmCorBJpTyQYLDoLe7h2GQ+EhQb4sH/Wg=; b=b3YzSmDYVq0JbFJOoCLr4ck2GJvzE7qDMQEdkGNrFfkJ9+EhLj6x+bM5 AUgbPAPEoFOpt/zsfuQG71ITmt4k4921bpz042n7t9dXhFfeYOIUmoKdg oPECwVqXyc5mclAtpyLtvf/ui7w0mROOauWTcNQBba0lnTWU71NJoGzUy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFACoYIlOtJV2b/2dsb2JhbABZgmUhgRLBZYEdFnSCJQEBAQQ6PwwEAgEIDgMEAQEBChQJBzIUCQgCBA4FCIdxAdQoF44FJzEHBoMegRQEqnKDLYFpQg X-IronPort-AV: E=Sophos;i="4.97,649,1389744000"; d="scan'208";a="27309959" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 13 Mar 2014 20:48:28 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2DKmSiG007210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 20:48:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 15:48:27 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YA== Date: Thu, 13 Mar 2014 20:48:27 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> <20140313200927.GF18110@pfrc> <20140313202743.GG18110@pfrc> In-Reply-To: <20140313202743.GG18110@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lglLylOpU3yrocfVCB6uvoujt1Q Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 20:48:37 -0000 Hi Jeff, Marc, BFDers, [Jeff wrote] > So, I suppose the suggested addition to the S-BFD logic is "in the absenc= e of > a P-bit, F will still be set for security purposes upon reflection." This is certainly lesser evil than other evil ideas (especially v2 BFD), I= 'll take it :) S-BFD authors/collaborators & BFDers, comments? (speak now or forever hold your peace) [Jeff wrote] > If a reflector wants to tell an Initiator to slow down, it would simply n= eed to > inject an additional packet (perhaps a DoS on its own, so should be > rate-limited) with the P bit set. This is effectively the "dueling poll" > scenario that had popped up much earlier in standardization. So bit it. [Marc wrote] > ah well, we simply don't have enough flags in the BFD packet. You are sur= e > we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-= ) I am very sure :) [Marc wrote] > But seriously: as the S-BFD sender is effectively talking to itself you d= o not > need P/F to synchronize two systems. The reflector can simply set the > Required Min RX Interval as it wants and the S-BFD sender adjusts. True that's definitely a possibility, but someone will surely argue that ch= anging interval w/o presence of P bit will violate RFC5880. [Marc wrote] > Also: as Jeff mentioned, without any "session state" on the reflector sid= e it > would be difficult to match any received F bit to a particular P sent out= ? With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector now.= Reflector can still send [P=3D1, F=3D0], but that is one-way-communication= /request. -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, March 13, 2014 4:28 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: > > > I may be mis-remembering the conversation or mis-reading the > > > document, but since the reflector is intended to be stateless why > > > would it expect to receive a Final from the Initiator? > > > > It doesn't, reflector doesn't expect F bit (hence best effort). P bit w= ill alert > initiator that parameter has changed (i.e. Required Min RX Interval has > changed). >=20 > Remember that the primary reason for the Required Min RX Interval in > regular BFD is that the receiver is also running a timer and will use tha= t for > its state by helping to adjust the sender's speed in a graceful fashion. >=20 > In this case, graceful is important since only the Initiator cares about = the > actual timing of the packets. >=20 > And even then, for our original scenario: >=20 > A---M---B >=20 > As long as each side doesn't respond to F packets (but sends them), I thi= nk > we're still good. I think this means you can keep the poll bit idea to h= elp > suggest an Initiator to slow down and still prevent DoS. In such a scena= rio, M > is injecting packets to A, with or without P, using B's addressing. With= out P, > A could still respond with F and B would drop it. >=20 > So, I suppose the suggested addition to the S-BFD logic is "in the absenc= e of > a P-bit, F will still be set for security purposes upon reflection." >=20 > If a reflector wants to tell an Initiator to slow down, it would simply n= eed to > inject an additional packet (perhaps a DoS on its own, so should be > rate-limited) with the P bit set. This is effectively the "dueling poll" > scenario that had popped up much earlier in standardization. >=20 > -- Jeff From nobody Thu Mar 13 13:53:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C3B1A075C for ; Thu, 13 Mar 2014 13:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.952 X-Spam-Level: **** X-Spam-Status: No, score=4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, URIBL_SBL=20, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-IYHrsl3x9L for ; Thu, 13 Mar 2014 13:53:15 -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 B150B1A09E8 for ; Thu, 13 Mar 2014 13:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3517; q=dns/txt; s=iport; t=1394743988; x=1395953588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7GRMi0IHWpj8ZZQQWZQQnewgxRfbhgC+S6S8dIXu/Bw=; b=Wn2LefksulFZCnDFR+fBjrn6mrsto5X7tQNAeRTwFS9AhejFsAk7w9g+ mvG/+OB2SxOZiiA7rHDy/LjjUEgPbSGK8UQW49eXsjz2w5iqJNiSmtwWZ purqAfTb6R2XeMJQzY/SGZyTsQ3RqRnBYCUvXQcPQkhQ3FpqOcsOE1FUD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAIcZIlOtJXG8/2dsb2JhbABZgmUhgRKpXJgKgR0WdIIlAQEBAwE6PwwEAgEIEQQBAQEKFAkHIREUCQgBAQQOBQiHXQMJCAHMfA2HHxeMRoFmMQcGgx6BFAEDlliOUoVIgy2CKw X-IronPort-AV: E=Sophos;i="4.97,649,1389744000"; d="scan'208";a="310138665" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2014 20:53:07 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2DKr7jp020595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 20:53:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 15:53:06 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Subject: RE: Possible addition to S-BFD use-case draft? Thread-Topic: Possible addition to S-BFD use-case draft? Thread-Index: Ac84hmdERRnvRqtWQuCLjKvrLSpA0QGjWRaAAAciN2D//+4EgIAAU3lA Date: Thu, 13 Mar 2014 20:53:05 +0000 Message-ID: References: <20140313182727.GM29320@pfrc> <290B3CE0-97A2-4970-BC93-8811082A4A94@gmail.com> In-Reply-To: <290B3CE0-97A2-4970-BC93-8811082A4A94@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CzXiCOvFX-qI8jAoqezidmMvntw Cc: "satoru.matsushima@g.softbank.co.jp" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 20:53:16 -0000 > -----Original Message----- > From: Sam Aldrin [mailto:sam.aldrin@gmail.com] > Sent: Thursday, March 13, 2014 4:47 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Bhatia, Manav (Manav) (manav.bhatia@alcatel- > lucent.com); Gregory Mirsky (gregory.mirsky@ericsson.com); Nagendra > Kumar Nainar (naikumar); satoru.matsushima@g.softbank.co.jp; rtg- > bfd@ietf.org > Subject: Re: Possible addition to S-BFD use-case draft? >=20 >=20 >=20 > Sent from my iPad >=20 > > On Mar 13, 2014, at 1:12 PM, "Nobo Akiya (nobo)" > wrote: > > > > Hi Jeff, > > > >> -----Original Message----- > >> From: Jeffrey Haas [mailto:jhaas@pfrc.org] > >> Sent: Thursday, March 13, 2014 2:27 PM > >> To: Nobo Akiya (nobo) > >> Cc: Sam Aldrin (sam.aldrin@gmail.com); Bhatia, Manav (Manav) > >> (manav.bhatia@alcatel-lucent.com); Gregory Mirsky > >> (gregory.mirsky@ericsson.com); Nagendra Kumar Nainar (naikumar); > >> satoru.matsushima@g.softbank.co.jp; rtg-bfd@ietf.org > >> Subject: Re: Possible addition to S-BFD use-case draft? > >> > >> Nobo, > >> > >>> On Wed, Mar 05, 2014 at 04:06:07PM +0000, Nobo Akiya (nobo) wrote: > >>> I'd like to propose a possible addition to the S-BFD use-case draft. > >>> > >>> BFD MPLS (RFC5884) states: > >>> > >>> [snip] > >>> If there are multiple alternate paths from an ingress LSR to an > >>> egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to > >>> determine each of these alternate paths. A BFD session SHOULD be > >>> established for each alternate path that is discovered. > >>> [snip] > >>> > >>> Above implies that a BFD session should be bootstrapped per > >>> alternate > >> (i.e. ECMP) path, but RFC does not have further details no how to > >> create/maintain multiple BFD MPLS sessions per FEC. Questions I have > are: > >>> * How should egress de-multiplex the bootstrap request per alternate > >> path? > >>> * If/when number of alternate paths changes or hash key changes: > >>> - how should ingress delete BFD sessions on egress? > >>> - re-bootstrapping set of sessions can be [relatively] > >>> inefficient as that > >> can consume time/resources. > >>> > >>> Alternative is to use S-BFD for multiple alternate paths for a FEC, > >>> which > >> eliminates the concerns raised from above questions ... and much > >> simpler to implement and operate. > >> > >> My impression is that the alternate paths are known via MPLS > >> traceroute and thus the BFD packet can have the appropriate label stac= k > added. > > > > Yes, known via MPLS traceroute. Say this produces 8 ECMP paths. How do > you bootstrap (and maintain) 8 BFD over MPLS sessions on this LSP? > Paths identified by MPLS trace route are not unique with label stack beca= use > Dst local host address also uniquely identifies the path. If the same is = used > for BFD, do you plan to use local host as Dst address as well? Agree. I think Jeff meant (label stack with unique EL). Yes BFD over MPLS mandates usage of locahost (or v4 localhost mapped v6), s= ee RFC5884. Whether MPLS traceroute discovered entropy can be used by BFD to traverse e= xpected path is a separate question. But assuming that it _is_ possible (wh= ether EL or non-EL w/ 3-tuple hashing), then how do we do BFD over MPLS per= ECMP paths of LSP was my question, and implying that S-BFD is much better = fit for this job :) -Nobo >=20 > Sam > > > > -Nobo > > > >> > >> -- Jeff (not terribly clueful here) From nobody Thu Mar 13 14:12:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5794B1A0A47 for ; Thu, 13 Mar 2014 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acPFR7YF25Pa for ; Thu, 13 Mar 2014 14:12:16 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6271A0A39 for ; Thu, 13 Mar 2014 14:12:15 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A61422AA0F; Thu, 13 Mar 2014 21:12:07 +0000 (GMT) Date: Thu, 13 Mar 2014 14:12:10 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140313141210586556.725b1651@sniff.de> In-Reply-To: References: <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> <20140313200927.GF18110@pfrc> <20140313202743.GG18110@pfrc> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Oa0SX0Hf5kP_vh4HQNcEh2nbr78 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 21:12:21 -0000 Hello Nobo, okay. Now there is one detail: the security logic is actually: (1) upon reflection of an S-BFD packet, set the F bit to 1 (2) when receiving a S-BFD packet for reflection and the F bit is set, then drop the packet (or punt but do not reflect). So far, so good. Say "A" is the S-BFD originator and "B" is the reflector. If you use the Poll sequence now for a parameter change from the B side, we would send out a packet from A in reply to B's P packet, that has the F bit set and is directed to B's reflector. And the security rule above will drop this packet. That's okay when the F-bit packet from A is an additional packet. RFC5880 is kind of stating this by saying When the other system receives a Poll, it immediately transmits a BFD Control packet with the Final (F) bit set, independent of any periodic BFD Control packets it may be sending (see section 6.8.7). but we may want to ensure that the periodic packets have no F bit set. Otherwise fine with it. Regards, Marc On Thu, 13 Mar 2014 20:48:27 +0000, Nobo Akiya (nobo) wrote: > > Hi Jeff, Marc, BFDers, > > [Jeff wrote] >> So, I suppose the suggested addition to the S-BFD logic is "in the >> absence of >> a P-bit, F will still be set for security purposes upon reflection." > > This is certainly lesser evil than other evil ideas (especially v2 > BFD), I'll take it :) > S-BFD authors/collaborators & BFDers, comments? > (speak now or forever hold your peace) > > [Jeff wrote] >> If a reflector wants to tell an Initiator to slow down, it would >> simply need to >> inject an additional packet (perhaps a DoS on its own, so should be >> rate-limited) with the P bit set. This is effectively the "dueling poll" >> scenario that had popped up much earlier in standardization. > > So bit it. > > [Marc wrote] >> ah well, we simply don't have enough flags in the BFD packet. You are sure >> we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) > > I am very sure :) > > [Marc wrote] >> But seriously: as the S-BFD sender is effectively talking to itself >> you do not >> need P/F to synchronize two systems. The reflector can simply set the >> Required Min RX Interval as it wants and the S-BFD sender adjusts. > > True that's definitely a possibility, but someone will surely argue > that changing interval w/o presence of P bit will violate RFC5880. > > [Marc wrote] >> Also: as Jeff mentioned, without any "session state" on the >> reflector side it >> would be difficult to match any received F bit to a particular P sent out? > > With new proposal by Jeff, [P=0, F=1] will be dropped by reflector > now. Reflector can still send [P=1, F=0], but that is > one-way-communication/request. > > -Nobo > >> -----Original Message----- >> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >> Sent: Thursday, March 13, 2014 4:28 PM >> To: Nobo Akiya (nobo) >> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>> I may be mis-remembering the conversation or mis-reading the >>>> document, but since the reflector is intended to be stateless why >>>> would it expect to receive a Final from the Initiator? >>> >>> It doesn't, reflector doesn't expect F bit (hence best effort). P >>> bit will alert >> initiator that parameter has changed (i.e. Required Min RX Interval has >> changed). >> >> Remember that the primary reason for the Required Min RX Interval in >> regular BFD is that the receiver is also running a timer and will >> use that for >> its state by helping to adjust the sender's speed in a graceful fashion. >> >> In this case, graceful is important since only the Initiator cares >> about the >> actual timing of the packets. >> >> And even then, for our original scenario: >> >> A---M---B >> >> As long as each side doesn't respond to F packets (but sends them), I think >> we're still good. I think this means you can keep the poll bit idea >> to help >> suggest an Initiator to slow down and still prevent DoS. In such a >> scenario, M >> is injecting packets to A, with or without P, using B's addressing. >> Without P, >> A could still respond with F and B would drop it. >> >> So, I suppose the suggested addition to the S-BFD logic is "in the >> absence of >> a P-bit, F will still be set for security purposes upon reflection." >> >> If a reflector wants to tell an Initiator to slow down, it would >> simply need to >> inject an additional packet (perhaps a DoS on its own, so should be >> rate-limited) with the P bit set. This is effectively the "dueling poll" >> scenario that had popped up much earlier in standardization. >> >> -- Jeff > From nobody Thu Mar 13 14:24:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BF61A0A46 for ; Thu, 13 Mar 2014 14:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaQy4glqOLZp for ; Thu, 13 Mar 2014 14:23:58 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD0E1A0778 for ; Thu, 13 Mar 2014 14:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5706; q=dns/txt; s=iport; t=1394745832; x=1395955432; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fp9O3y6+NjC6vqar/PZZxULC3qF8SN23MgVgyjfPfvQ=; b=N1u9OW4LRokSU6ArLJHoLUGErT3KZCHqzNGNr1Zsvk/ebgCZxt7N0JoZ 5z5wc1JKE7sIIPJBxJZqNMGPcNJlTYVvX5y2Xh7ub0b+LV/pKvRNACKHq Pc9Zy/WOxDFoUB/65JqcY421wBopHk37oWA4IwX+NW9epEWx3XebUQWl0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAIggIlOtJXHB/2dsb2JhbABZgmUhgRLBb4EdFnSCJQEBAQMBOj8FBwQCAQgRBAEBAQoUCQcyFAkIAgQOBQiHaQgB1DcXjgUnMQcGgx6BFASqcoMtgWlC X-IronPort-AV: E=Sophos;i="4.97,649,1389744000"; d="scan'208";a="27308440" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-6.cisco.com with ESMTP; 13 Mar 2014 21:23:51 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2DLNpBY029435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 21:23:51 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 16:23:51 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAALrm8AAAohEVA= Date: Thu, 13 Mar 2014 21:23:50 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> <20140313200927.GF18110@pfrc> <20140313202743.GG18110@pfrc> <20140313141210586556.725b1651@sniff.de> In-Reply-To: <20140313141210586556.725b1651@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4Ny1v98F2eMF6SgeA1mmaahIsQw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 21:24:00 -0000 Hi Marc, > but we may want to ensure that the periodic packets have no F bit set. Agree, we have to be crystal clear on this point in the base document. > Otherwise fine with it. Excellent & thanks! -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Thursday, March 13, 2014 5:12 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello Nobo, >=20 > okay. Now there is one detail: the security logic is actually: >=20 > (1) upon reflection of an S-BFD packet, set the F bit to 1 > (2) when receiving a S-BFD packet for reflection and the F bit is set, th= en > drop the packet (or punt but do not reflect). >=20 >=20 > So far, so good. Say "A" is the S-BFD originator and "B" is the > reflector. If you use the Poll sequence now for a parameter change from > the B side, we would send out a packet from A in reply to B's P packet, > that has the F bit set and is directed to B's reflector. And the > security rule above will drop this packet. >=20 > That's okay when the F-bit packet from A is an additional packet. > RFC5880 is kind of stating this by saying >=20 > When the other system receives a > Poll, it immediately transmits a BFD Control packet with the Final > (F) bit set, independent of any periodic BFD Control packets it may > be sending (see section 6.8.7). >=20 > but we may want to ensure that the periodic packets have no F bit set. > Otherwise fine with it. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Thu, 13 Mar 2014 20:48:27 +0000, Nobo Akiya (nobo) wrote: > > > > Hi Jeff, Marc, BFDers, > > > > [Jeff wrote] > >> So, I suppose the suggested addition to the S-BFD logic is "in the > >> absence of > >> a P-bit, F will still be set for security purposes upon reflection." > > > > This is certainly lesser evil than other evil ideas (especially v2 > > BFD), I'll take it :) > > S-BFD authors/collaborators & BFDers, comments? > > (speak now or forever hold your peace) > > > > [Jeff wrote] > >> If a reflector wants to tell an Initiator to slow down, it would > >> simply need to > >> inject an additional packet (perhaps a DoS on its own, so should be > >> rate-limited) with the P bit set. This is effectively the "dueling po= ll" > >> scenario that had popped up much earlier in standardization. > > > > So bit it. > > > > [Marc wrote] > >> ah well, we simply don't have enough flags in the BFD packet. You are > sure > >> we don't want a BFD "v2" to add another 32/64 bit for future flag use?= ;-) > > > > I am very sure :) > > > > [Marc wrote] > >> But seriously: as the S-BFD sender is effectively talking to itself > >> you do not > >> need P/F to synchronize two systems. The reflector can simply set the > >> Required Min RX Interval as it wants and the S-BFD sender adjusts. > > > > True that's definitely a possibility, but someone will surely argue > > that changing interval w/o presence of P bit will violate RFC5880. > > > > [Marc wrote] > >> Also: as Jeff mentioned, without any "session state" on the > >> reflector side it > >> would be difficult to match any received F bit to a particular P sent = out? > > > > With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector > > now. Reflector can still send [P=3D1, F=3D0], but that is > > one-way-communication/request. > > > > -Nobo > > > >> -----Original Message----- > >> From: Jeffrey Haas [mailto:jhaas@pfrc.org] > >> Sent: Thursday, March 13, 2014 4:28 PM > >> To: Nobo Akiya (nobo) > >> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org > >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: > >>>> I may be mis-remembering the conversation or mis-reading the > >>>> document, but since the reflector is intended to be stateless why > >>>> would it expect to receive a Final from the Initiator? > >>> > >>> It doesn't, reflector doesn't expect F bit (hence best effort). P > >>> bit will alert > >> initiator that parameter has changed (i.e. Required Min RX Interval ha= s > >> changed). > >> > >> Remember that the primary reason for the Required Min RX Interval in > >> regular BFD is that the receiver is also running a timer and will > >> use that for > >> its state by helping to adjust the sender's speed in a graceful fashio= n. > >> > >> In this case, graceful is important since only the Initiator cares > >> about the > >> actual timing of the packets. > >> > >> And even then, for our original scenario: > >> > >> A---M---B > >> > >> As long as each side doesn't respond to F packets (but sends them), I > think > >> we're still good. I think this means you can keep the poll bit idea > >> to help > >> suggest an Initiator to slow down and still prevent DoS. In such a > >> scenario, M > >> is injecting packets to A, with or without P, using B's addressing. > >> Without P, > >> A could still respond with F and B would drop it. > >> > >> So, I suppose the suggested addition to the S-BFD logic is "in the > >> absence of > >> a P-bit, F will still be set for security purposes upon reflection." > >> > >> If a reflector wants to tell an Initiator to slow down, it would > >> simply need to > >> inject an additional packet (perhaps a DoS on its own, so should be > >> rate-limited) with the P bit set. This is effectively the "dueling po= ll" > >> scenario that had popped up much earlier in standardization. > >> > >> -- Jeff > > From nobody Thu Mar 13 15:47:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0CB1A0758 for ; Thu, 13 Mar 2014 15:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-m8zW6Acf1H for ; Thu, 13 Mar 2014 15:47:32 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 238631A074C for ; Thu, 13 Mar 2014 15:47:32 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so1752138pab.22 for ; Thu, 13 Mar 2014 15:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=b0Bf/TMzhm6FRdcOW67rTKWhBmXo6ZOkAv2chX8GrxE=; b=dSdn7GdVP/HJGAnR6MSPvytPQyA5VLUOYt9pjXSJrpkA2mMk9vcS4+4FiPVtjsQ7/U HNQ8HFip3jDAyPgM/NNWsuIOSoxzlVQWaKRHLt1fgs3Dp1H5MGJT2pD6Y4ZZP8g9VOKf HD3P0tpc5Kc8oKKP02VFA2j+uOxk3trpZueosYyJEyG9UPU4WdY6RogQo/ZpQyvJAd6e L/vQWM8FWUZZ9EXJUd0KwoziWWkw7prEgLyT7DZC/fcADJvw6nItSv1Lr0l6wCyhyiPC saYsww5mQvoIwXZlJSG0qDbLCwfyi9pMOn6JnSOFKXfSEYVNLi8iWVxF4Xt8Gtxc1T2E cmWw== X-Received: by 10.67.2.34 with SMTP id bl2mr5374979pad.58.1394750837356; Thu, 13 Mar 2014 15:47:17 -0700 (PDT) Received: from [192.168.1.4] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id vb7sm10374961pbc.13.2014.03.13.15.47.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 15:47:16 -0700 (PDT) References: <315041E4211CB84E86EF7C25A2AB583D339CBC11@xmb-rcd-x15.cisco.com> <20140310152610918599.225ad953@sniff.de> <20140311165705373444.759ede3c@sniff.de> <20140313182432.GL29320@pfrc> <20140313113557056990.2cc36f2b@sniff.de> <20140313184936.GB18110@pfrc> <20140313200927.GF18110@pfrc> <20140313202743.GG18110@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11D167) From: Sam Aldrin Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Date: Thu, 13 Mar 2014 15:47:14 -0700 To: "Nobo Akiya (nobo)" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RDNdVDiDcxozdpljBwnbT6Fd4q8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 22:47:34 -0000 Comments inline. Sent from my iPad > On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" wrote: >=20 >=20 > Hi Jeff, Marc, BFDers, >=20 > [Jeff wrote] >> So, I suppose the suggested addition to the S-BFD logic is "in the absenc= e of >> a P-bit, F will still be set for security purposes upon reflection." >=20 > This is certainly lesser evil than other evil ideas (especially v2 BFD), I= 'll take it :) > S-BFD authors/collaborators & BFDers, comments? > (speak now or forever hold your peace) Catching on this long email thread, finally.=20 I too prefer not going v2 way, as it creates more complexity or open up many= more issues. P/F bits as suggested by Jeff is a good option and we should use it. Base do= cument should document on how those bits should be used, that includes any i= nterval change. >=20 > [Jeff wrote] >> If a reflector wants to tell an Initiator to slow down, it would simply n= eed to >> inject an additional packet (perhaps a DoS on its own, so should be >> rate-limited) with the P bit set. This is effectively the "dueling poll"= >> scenario that had popped up much earlier in standardization. >=20 > So bit it. >=20 > [Marc wrote] >> ah well, we simply don't have enough flags in the BFD packet. You are sur= e >> we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-= ) >=20 > I am very sure :) >=20 > [Marc wrote] >> But seriously: as the S-BFD sender is effectively talking to itself you d= o not >> need P/F to synchronize two systems. The reflector can simply set the >> Required Min RX Interval as it wants and the S-BFD sender adjusts. >=20 > True that's definitely a possibility, but someone will surely argue that c= hanging interval w/o presence of P bit will violate RFC5880. If it deviates from the way the P bit is presently being used, true. But if S= -BFD could set rx interval differently to regular BFD as long as we document= it right, we wouldn't be violating RFC5880, IMO. Do you think RFC is rigid= about interval change? >=20 > [Marc wrote] >> Also: as Jeff mentioned, without any "session state" on the reflector sid= e it >> would be difficult to match any received F bit to a particular P sent out= ? >=20 > With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector now= . Reflector can still send [P=3D1, F=3D0], but that is one-way-communication= /request. Nod. Sam >=20 > -Nobo >=20 >> -----Original Message----- >> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >> Sent: Thursday, March 13, 2014 4:28 PM >> To: Nobo Akiya (nobo) >> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>=20 >> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>> I may be mis-remembering the conversation or mis-reading the >>>> document, but since the reflector is intended to be stateless why >>>> would it expect to receive a Final from the Initiator? >>>=20 >>> It doesn't, reflector doesn't expect F bit (hence best effort). P bit wi= ll alert >> initiator that parameter has changed (i.e. Required Min RX Interval has >> changed). >>=20 >> Remember that the primary reason for the Required Min RX Interval in >> regular BFD is that the receiver is also running a timer and will use tha= t for >> its state by helping to adjust the sender's speed in a graceful fashion. >>=20 >> In this case, graceful is important since only the Initiator cares about t= he >> actual timing of the packets. >>=20 >> And even then, for our original scenario: >>=20 >> A---M---B >>=20 >> As long as each side doesn't respond to F packets (but sends them), I thi= nk >> we're still good. I think this means you can keep the poll bit idea to h= elp >> suggest an Initiator to slow down and still prevent DoS. In such a scena= rio, M >> is injecting packets to A, with or without P, using B's addressing. With= out P, >> A could still respond with F and B would drop it. >>=20 >> So, I suppose the suggested addition to the S-BFD logic is "in the absenc= e of >> a P-bit, F will still be set for security purposes upon reflection." >>=20 >> If a reflector wants to tell an Initiator to slow down, it would simply n= eed to >> inject an additional packet (perhaps a DoS on its own, so should be >> rate-limited) with the P bit set. This is effectively the "dueling poll"= >> scenario that had popped up much earlier in standardization. >>=20 >> -- Jeff >=20 From nobody Thu Mar 13 18:30:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A321A07E9 for ; Thu, 13 Mar 2014 18:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.952 X-Spam-Level: **** X-Spam-Status: No, score=4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, URIBL_SBL=20, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHzszKOUv_ag for ; Thu, 13 Mar 2014 18:30:34 -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 AED2F1A07D9 for ; Thu, 13 Mar 2014 18:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8891; q=dns/txt; s=iport; t=1394760628; x=1395970228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Pd6SYKLZY8ADOfQhkJ4ws6QMCx3RHhIoxVRGbp8OZZk=; b=WuGFxcwvRNfOtzwp6LwfEnjassLlyN1iWY1UktfY9Qq1Z6RLUORDUaiI OmofkUMHx09C/tWNwjRoKWOTxPQ9FZEiuZiMRn11APdNp6WyAeAntVRNb SEiNUzA7jMXfsd2PL2/c9vYRgkyYvK7eSFEZ5zlGFXtRuzMglEqjVg9EY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHVaIlOtJXHB/2dsb2JhbABZgmUhO1epZ5gKgRoWdIIlAQEBAwEOLCsUBQcEAgEIEQQBAQEKFAkHIREUCQgCBA4FCBOHSgMJCAEMzDoNhx8XjEYpgRYnBisHAgSDHoEUBJQVgkODH4szhUiDLYFpQg X-IronPort-AV: E=Sophos;i="4.97,650,1389744000"; d="scan'208";a="310231137" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2014 01:30:27 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2E1URoi008373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 01:30:27 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 20:30:27 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Subject: RE: Possible addition to S-BFD use-case draft? Thread-Topic: Possible addition to S-BFD use-case draft? Thread-Index: Ac84hmdERRnvRqtWQuCLjKvrLSpA0QGjWRaAAAciN2D//+4EgIAAU3lA//9ssQCAAElbgIAAUwmg///t6QCAAFIwQA== Date: Fri, 14 Mar 2014 01:30:27 +0000 Message-ID: References: <36476226-6A3C-4179-BC10-1C75FA0A61DA@gmail.com> <8E8061CF-0548-448E-8B0B-BB42AEB9C408@gmail.com> In-Reply-To: <8E8061CF-0548-448E-8B0B-BB42AEB9C408@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oLi_ZvhvGW6clBmEtHwSbJAqdDY Cc: "satoru.matsushima@g.softbank.co.jp" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 Mar 2014 01:30:37 -0000 Hi Sam, > >>> While path trace is still required, S-BFD eliminates the need for > >>> bootstrapping Discrim negotiation. > >> I understand the elimination of discrimination negotiation with > >> S-BFD, I personally still need to understand the value of running per > ECMP path. > > > > Right, it's a use-case draft, so that aspect is critical. Sorry for not= bringing > that up earlier. > > Detection of traffic black hole on MPLS network is what I had in mind, = with > LDP being the primary motivation for now. > Makes sense. I think it is important for non LDP cases as well, like FAT = PW. True it could apply there as well ... although I have my opinion on which *= layer* to do ECMP in-band monitor :) > With type-9 multi path type of LSP ping, one could determine the label st= ack > of Packet for each of the ECMP paths. > Which makes a case for http://datatracker.ietf.org/doc/draft-akiya-mpls- > entropy-lsp-ping/?include_text=3D1 :D :) > One solution question (not applicable for use case draft) I have is, with= the > presence of EL, will intermediate nodes still use fields beyond label sta= ck > for load balance? Like IP/UDP header? > As that varies between MPLS and BFD, mapping of 1:1 may not yield right > results, right? MPLS trace and S-BFD can use same IP src/dst, but UDP ports will vary. Thus= in a non-EL environment, all LSRs will need to use 3-tuple hashing that ex= cludes UDP ports. This is not limitation with just MPLS trace and S-BFD (or= BFD). This is applicable to all other OAM techniques which employ MPLS tra= ceroute to discover hash keys and use *something else* to traverse specific= ECMP path using the hash keys. For example: http://datatracker.ietf.org/do= c/draft-geib-spring-oam-usecase/ With EL though, RFC6790 defines transit LSR behavior this way. [snip] Some transit LSRs look beyond the label stack for better load- balancing information. This is a simple, backward-compatible approach in networks where some ingress LSRs impose ELs and others don't. However, this is of limited incremental value if an EL is indeed present and requires more packet processing from the LSR. A transit LSR MAY choose to parse the label stack for the presence of the ELI and look beyond the label stack only if it does not find it, thus retaining the old behavior when needed, yet avoiding unnecessary work if not needed. [snip] Which means, if ELI/EL is present, then stuff beyond label stack will not b= e used for load balance purpose. This is one of the major strength of EL fr= om OAM perspective. So can we get that one added into S-BFD use-case draft? :) -Nobo >=20 > -sam > > > > -Nobo > > > >> -----Original Message----- > >> From: Sam Aldrin [mailto:sam.aldrin@gmail.com] > >> Sent: Thursday, March 13, 2014 5:21 PM > >> To: Nagendra Kumar Nainar (naikumar) > >> Cc: Nobo Akiya (nobo); Jeffrey Haas; Bhatia, Manav (Manav) > >> (manav.bhatia@alcatel-lucent.com); Gregory Mirsky > >> (gregory.mirsky@ericsson.com); satoru.matsushima@g.softbank.co.jp; > >> rtg- bfd@ietf.org > >> Subject: Re: Possible addition to S-BFD use-case draft? > >> > >> > >> > >> Sent from my iPad > >> > >>> On Mar 13, 2014, at 1:58 PM, "Nagendra Kumar Nainar (naikumar)" > >> wrote: > >>> > >>> Hi > >>> > >>> Agree. I think Jeff meant (label stack with unique EL). > >>> > >>> Yes BFD over MPLS mandates usage of locahost (or v4 localhost mapped > >>> v6), see RFC5884. > >> Ah! Forgot about that. > >>> > >>> Whether MPLS traceroute discovered entropy can be used by BFD to > >>> traverse expected path is a separate question. But assuming that it > >>> _is_ possible (whether EL or non-EL w/ 3-tuple hashing), then how do > >>> we do BFD over MPLS per ECMP paths of LSP was my question, and > >>> implying that S-BFD is much better fit for this job :) > >>> > >>> > >>> > >>> I think yes. While trace route will help with identifying > >>> the ECMP paths and the possible entropy (EL, address range or both), > >>> traditional BFD still need additional step to bootstrap the Discrim > >>> for each session (over each path). > >> Sorry for diverging here, are you saying EL is used for path tracing? > >> Has anyone implemented that? Would definitely love to talk to them > offline. > >>> > >>> While path trace is still required, S-BFD eliminates the need for > >>> bootstrapping Discrim negotiation. > >> I understand the elimination of discrimination negotiation with > >> S-BFD, I personally still need to understand the value of running per > ECMP path. > >> > >> Sam > >>> > >>> Thanks, > >>> Nagendra > >>> > >>>> On 3/13/14 4:53 PM, "Nobo Akiya (nobo)" wrote: > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Sam Aldrin [mailto:sam.aldrin@gmail.com] > >>>>> Sent: Thursday, March 13, 2014 4:47 PM > >>>>> To: Nobo Akiya (nobo) > >>>>> Cc: Jeffrey Haas; Bhatia, Manav (Manav) (manav.bhatia@alcatel- > >>>>> lucent.com); Gregory Mirsky (gregory.mirsky@ericsson.com); > >>>>> Nagendra Kumar Nainar (naikumar); > >>>>> satoru.matsushima@g.softbank.co.jp; rtg- bfd@ietf.org > >>>>> Subject: Re: Possible addition to S-BFD use-case draft? > >>>>> > >>>>> > >>>>> > >>>>> Sent from my iPad > >>>>> > >>>>>>> On Mar 13, 2014, at 1:12 PM, "Nobo Akiya (nobo)" > >>>>>>> > >>>>>> wrote: > >>>>>> > >>>>>> Hi Jeff, > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] > >>>>>>> Sent: Thursday, March 13, 2014 2:27 PM > >>>>>>> To: Nobo Akiya (nobo) > >>>>>>> Cc: Sam Aldrin (sam.aldrin@gmail.com); Bhatia, Manav (Manav) > >>>>>>> (manav.bhatia@alcatel-lucent.com); Gregory Mirsky > >>>>>>> (gregory.mirsky@ericsson.com); Nagendra Kumar Nainar > (naikumar); > >>>>>>> satoru.matsushima@g.softbank.co.jp; rtg-bfd@ietf.org > >>>>>>> Subject: Re: Possible addition to S-BFD use-case draft? > >>>>>>> > >>>>>>> Nobo, > >>>>>>> > >>>>>>>> On Wed, Mar 05, 2014 at 04:06:07PM +0000, Nobo Akiya (nobo) > wrote: > >>>>>>>> I'd like to propose a possible addition to the S-BFD use-case dr= aft. > >>>>>>>> > >>>>>>>> BFD MPLS (RFC5884) states: > >>>>>>>> > >>>>>>>> [snip] > >>>>>>>> If there are multiple alternate paths from an ingress LSR to an > >>>>>>>> egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used > >>>>>>>> to determine each of these alternate paths. A BFD session > >>>>>>>> SHOULD be established for each alternate path that is discovered= . > >>>>>>>> [snip] > >>>>>>>> > >>>>>>>> Above implies that a BFD session should be bootstrapped per > >>>>>>>> alternate > >>>>>>> (i.e. ECMP) path, but RFC does not have further details no how > >>>>>>> to create/maintain multiple BFD MPLS sessions per FEC. Questions > >>>>>>> I have > >>>>> are: > >>>>>>>> * How should egress de-multiplex the bootstrap request per > >>>>>>>> alternate > >>>>>>> path? > >>>>>>>> * If/when number of alternate paths changes or hash key changes: > >>>>>>>> - how should ingress delete BFD sessions on egress? > >>>>>>>> - re-bootstrapping set of sessions can be [relatively] > >>>>>>>> inefficient as that > >>>>>>> can consume time/resources. > >>>>>>>> > >>>>>>>> Alternative is to use S-BFD for multiple alternate paths for a > >>>>>>>> FEC, which > >>>>>>> eliminates the concerns raised from above questions ... and much > >>>>>>> simpler to implement and operate. > >>>>>>> > >>>>>>> My impression is that the alternate paths are known via MPLS > >>>>>>> traceroute and thus the BFD packet can have the appropriate > >>>>>>> label > >>>>> stack > >>>>> added. > >>>>>> > >>>>>> Yes, known via MPLS traceroute. Say this produces 8 ECMP paths. > >>>>>> How do > >>>>> you bootstrap (and maintain) 8 BFD over MPLS sessions on this LSP? > >>>>> Paths identified by MPLS trace route are not unique with label > >>>>> stack because Dst local host address also uniquely identifies the > >>>>> path. If the same is used for BFD, do you plan to use local host > >>>>> as Dst address as well? > >>>> > >>>> Agree. I think Jeff meant (label stack with unique EL). > >>>> > >>>> Yes BFD over MPLS mandates usage of locahost (or v4 localhost > >>>> mapped v6), see RFC5884. > >>>> > >>>> Whether MPLS traceroute discovered entropy can be used by BFD to > >>>> traverse expected path is a separate question. But assuming that it > >>>> _is_ possible (whether EL or non-EL w/ 3-tuple hashing), then how > >>>> do we do BFD over MPLS per ECMP paths of LSP was my question, and > >>>> implying that S-BFD is much better fit for this job :) > >>>> > >>>> -Nobo > >>>> > >>>>> > >>>>> Sam > >>>>>> > >>>>>> -Nobo > >>>>>> > >>>>>>> > >>>>>>> -- Jeff (not terribly clueful here) > >>> From nobody Thu Mar 13 18:39:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8FC1A07C1 for ; Thu, 13 Mar 2014 18:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5Un7OS-AJUm for ; Thu, 13 Mar 2014 18:39:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8781A0805 for ; Thu, 13 Mar 2014 18:39:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140314013931.27372.24102.idtracker@ietfa.amsl.com> Date: Thu, 13 Mar 2014 18:39:31 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/us9g1J6VJIvRM-BLwAuXJuIRVXc X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 01:39:34 -0000 Changed milestone "Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard", resolved as "Done". URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Fri Mar 14 18:51:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE41A0260 for ; Fri, 14 Mar 2014 18:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8icwd4WsXmU for ; Fri, 14 Mar 2014 18:51:23 -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 28ABA1A0268 for ; Fri, 14 Mar 2014 18:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4167; q=dns/txt; s=iport; t=1394848276; x=1396057876; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xYhYfqNEgMIvDis8sMP6aqUJqvYbsjjD6rT0qn0qncA=; b=YYxC7+gsoMKDms00nE6k3WRJa7JzC9+2Jsyv5l5vdrYYuiS+X6eNio5C B7WSKA6BUsKenZlmXjE3wJNgqESRqEBfFWkCsgLXEhHxfQr6XU55tPhyT 7w1dvUHToQA/3oLPdLzh1ZoRabBvUqcuLzglluGOlGT+Mb31eRhTSvRGg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAF+xI1OtJV2d/2dsb2JhbABZgmUhgRLBf4EUFnSCJQEBAQMBDlcUBQsCAQgiJDIlAgQODYdpCAHUKheODycxB4MkgRQEiRmhWoMtgWlC X-IronPort-AV: E=Sophos;i="4.97,658,1389744000"; d="scan'208";a="310306177" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 15 Mar 2014 01:51:16 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2F1pFlw026192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Mar 2014 01:51:15 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 20:51:15 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Subject: RE: Possible addition to S-BFD use-case draft? Thread-Topic: Possible addition to S-BFD use-case draft? Thread-Index: Ac84hmdERRnvRqtWQuCLjKvrLSpA0QGjWRaAAAciN2D//+4EgIAAU3lA//9ssQCAAElbgIAAUwmg///t6QCAAFIwQP//tQmAAAkllzAAKMrpAAAKBixA Date: Sat, 15 Mar 2014 01:51:14 +0000 Message-ID: References: <36476226-6A3C-4179-BC10-1C75FA0A61DA@gmail.com> <8E8061CF-0548-448E-8B0B-BB42AEB9C408@gmail.com> <0D89FFA2-A946-4883-8C04-DC0F399BE66A@gmail.com> <5911A38B-2977-49CD-957F-679D55B16715@gmail.com> In-Reply-To: <5911A38B-2977-49CD-957F-679D55B16715@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.235.14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dSqCfIuuaJz2kGF9o1d-b_INaZk Cc: "satoru.matsushima@g.softbank.co.jp" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 15 Mar 2014 01:51:25 -0000 Hi Sam, > With EL though, RFC6790 defines transit LSR behavior this way. >=20 > [snip] > =A0Some transit LSRs look beyond the label stack for better load- > =A0balancing information. =A0This is a simple, backward-compatible > =A0approach in networks where some ingress LSRs impose ELs and others > =A0don't. =A0However, this is of limited incremental value if an EL is > =A0indeed present and requires more packet processing from the LSR. =A0A > =A0transit LSR MAY choose to parse the label stack for the presence of > =A0the ELI and look beyond the label stack only if it does not find it, > =A0thus retaining the old behavior when needed, yet avoiding unnecessary > =A0work if not needed. > [snip] >=20 > Which means, if ELI/EL is present, then stuff beyond label stack will not= be > used for load balance purpose. This is one of the major strength of EL fr= om > OAM perspective. > Do you think this will be true for legacy hardware as well? How will they > know they need to special process EL and not to look at IP header for has= h > computation? >=20 > I believe the assumption by RFC6790 is, if a product has implemented > support for ELI/EL, it has been updated to not look at stuff beyond label > stack when ELI/EL is present. And that should be possible because ELI is = a > special label. > Sure. But that is for implementations which understand RFC6790. What > about the existing h/w which are already deployed? I just went to back emails threads with Curtis Villamizar in MPLS list. RFC= 6790 describes that there's no point in looking for other entropies beyond = first EL found, but there is nothing in RFC6790 that prevents implementatio= ns from looking further beyond EL. RFC4389 on the other hand was originally= designed to handle implementations that load balances on label OR IP. With= so many flavors of load balancing implementations, it's very difficult for= any OAM to cover all. A reasonable approach may be to go with coverage ove= r common implementations, like approach taken by RFC4379. > So can we get that one added into S-BFD use-case draft? :) > Please get me the text and will add, not a problem :D >=20 > Excellent! >=20 > How about something like this: >=20 > 3.9. =A0MPLS BFD Session Per ECMP Path >=20 > =A0=A0BFD for MPLS, defined in [RFC5884], describes procedures to run BFD > =A0=A0as LSP in-band continuity check mechanism, through usage of MPLS ec= ho > =A0=A0request [RFC4379] to bootstrap the BFD session on the egress node. > =A0=A0Section 4 of [RFC5884] also describes a possibility of running > =A0=A0multiple BFD sessions per alternative paths of LSP. =A0However, det= ails > =A0=A0on how to bootstrap and maintain correct set of BFD sessions on the > =A0=A0egress node is absent. >=20 > =A0=A0When a LSP has ECMP, it is desirable to run in-band monitoring that > =A0=A0exercises every path of ECMP. =A0Otherwise there will be scenarios > =A0=A0where in-band BFD session remains up through one path but traffic i= s > =A0=A0black-holing over another path. =A0One way to achieve BFD session p= er > =A0=A0ECMP path of LSP is to define procedures that updates [RFC5884] in > =A0=A0terms of how to bootstrap and maintain correct set of BFD sessions = on > =A0=A0the egress node. =A0However, that may require constant use of MPLS = echo > =A0=A0request messages to create and delete BFD sessions on the egress > =A0=A0node, when ECMP paths and/or corresponding load balance hash keys > =A0=A0change. =A0If a BFD session over any paths of LSP can be instantiat= ed, > =A0=A0stopped and resumed without requiring additional procedures of > =A0=A0bootstrapping via MPLS echo request, it would simplify > =A0=A0implementations and operations, and benefits network devices as les= s > =A0=A0processing are required by them. >=20 > Sure will add. Thanks! > Did I miss any other additions apart from this? Will spin a new version i= n 10 > days. > Will add any, if sent to me by then. This is the only one that was brought up to the list so far. If others have= anything, now would be a good time to chime in. -Nobo From nobody Mon Mar 17 03:34:01 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2611A03C9 for ; Mon, 17 Mar 2014 03:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23RvIOtu4nou for ; Mon, 17 Mar 2014 03:33:57 -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 A88B31A03C7 for ; Mon, 17 Mar 2014 03:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5424; q=dns/txt; s=iport; t=1395052430; x=1396262030; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=F0BsYRmh9kDFC2jtq3qCviAAqxslyGhp2K6TsRuGjPk=; b=dXln5tTt7IKvcmLwu693yPuQSpMGtBtxTn8jtjjWHsOTbX1s9plrMq6c obKULBjEoBCWh3jFw20qVqqzXpLhkAtr87MpoSyF2KDyPTl37kGdLoOFN j0+mtYNu1GugkQ8XgWp9J0O2dZrGeFv0QT8KqgH3hHLT8IBRI6Vj8piNt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAPTOJlOtJV2d/2dsb2JhbABZgwaBEqlzmA6BGhZ0giUBAQEEOj8MBgEIEQQBAQEeCSgRFAkIAgQBDQWHZQMRywsNhy8XjFCBNgoHAR0zBwaEMgEDllmBbYxnhUiDLYFpCRci X-IronPort-AV: E=Sophos;i="4.97,669,1389744000"; d="scan'208";a="310795291" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 17 Mar 2014 10:33:49 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2HAXnJv011365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 10:33:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.240]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 05:33:49 -0500 From: "Girija Raghavendra Rao (giraghav)" To: Sam Aldrin , "Nobo Akiya (nobo)" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPQcxhN/XAwSol50e0e7bZ4QP6Jw== Date: Mon, 17 Mar 2014 10:33:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.62] Content-Type: text/plain; charset="us-ascii" Content-ID: <20D4EB23E0251F4A901989B1017CCF73@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KjxnWsulzbsCzS-KFZTSMcGkkwU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 10:34:00 -0000 Hi Jeff, Marc, Nobo, BFDers, If using of "D" bit to differentiate initiator/Reflector generated packets is not preferred, how about the second option listed in the start of this thread? 2. Use of State field in the BFD control packets: Initiator will always send packets with State set to "DOWN" and reflector will send back packets with state field set to "UP. Reflectors will never reflect any packets with state as "UP". However the only issue is the use of state field differently i.e. state in the S-BFD control packet from initiator does not reflect the local state which is anyway not significant at reflector. Thanks & Regards R.Girija On 14/03/14 4:17 AM, "Sam Aldrin" wrote: >Comments inline. > >Sent from my iPad > >> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" wrote: >>=20 >>=20 >> Hi Jeff, Marc, BFDers, >>=20 >> [Jeff wrote] >>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>absence of >>> a P-bit, F will still be set for security purposes upon reflection." >>=20 >> This is certainly lesser evil than other evil ideas (especially v2 >>BFD), I'll take it :) >> S-BFD authors/collaborators & BFDers, comments? >> (speak now or forever hold your peace) >Catching on this long email thread, finally. > >I too prefer not going v2 way, as it creates more complexity or open up >many more issues. >P/F bits as suggested by Jeff is a good option and we should use it. Base >document should document on how those bits should be used, that includes >any interval change. >>=20 >> [Jeff wrote] >>> If a reflector wants to tell an Initiator to slow down, it would >>>simply need to >>> inject an additional packet (perhaps a DoS on its own, so should be >>> rate-limited) with the P bit set. This is effectively the "dueling >>>poll" >>> scenario that had popped up much earlier in standardization. >>=20 >> So bit it. >>=20 >> [Marc wrote] >>> ah well, we simply don't have enough flags in the BFD packet. You are >>>sure >>> we don't want a BFD "v2" to add another 32/64 bit for future flag use? >>>;-) >>=20 >> I am very sure :) >>=20 >> [Marc wrote] >>> But seriously: as the S-BFD sender is effectively talking to itself >>>you do not >>> need P/F to synchronize two systems. The reflector can simply set the >>> Required Min RX Interval as it wants and the S-BFD sender adjusts. >>=20 >> True that's definitely a possibility, but someone will surely argue >>that changing interval w/o presence of P bit will violate RFC5880. >If it deviates from the way the P bit is presently being used, true. But >if S-BFD could set rx interval differently to regular BFD as long as we >document it right, we wouldn't be violating RFC5880, IMO. Do you think >RFC is rigid about interval change? >>=20 >> [Marc wrote] >>> Also: as Jeff mentioned, without any "session state" on the reflector >>>side it >>> would be difficult to match any received F bit to a particular P sent >>>out? >>=20 >> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector n= ow. >>Reflector can still send [P=3D1, F=3D0], but that is >>one-way-communication/request. > >Nod. > >Sam >>=20 >> -Nobo >>=20 >>> -----Original Message----- >>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>> Sent: Thursday, March 13, 2014 4:28 PM >>> To: Nobo Akiya (nobo) >>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>=20 >>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>>> I may be mis-remembering the conversation or mis-reading the >>>>> document, but since the reflector is intended to be stateless why >>>>> would it expect to receive a Final from the Initiator? >>>>=20 >>>> It doesn't, reflector doesn't expect F bit (hence best effort). P bit >>>>will alert >>> initiator that parameter has changed (i.e. Required Min RX Interval has >>> changed). >>>=20 >>> Remember that the primary reason for the Required Min RX Interval in >>> regular BFD is that the receiver is also running a timer and will use >>>that for >>> its state by helping to adjust the sender's speed in a graceful >>>fashion. >>>=20 >>> In this case, graceful is important since only the Initiator cares >>>about the >>> actual timing of the packets. >>>=20 >>> And even then, for our original scenario: >>>=20 >>> A---M---B >>>=20 >>> As long as each side doesn't respond to F packets (but sends them), I >>>think >>> we're still good. I think this means you can keep the poll bit idea >>>to help >>> suggest an Initiator to slow down and still prevent DoS. In such a >>>scenario, M >>> is injecting packets to A, with or without P, using B's addressing. >>>Without P, >>> A could still respond with F and B would drop it. >>>=20 >>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>absence of >>> a P-bit, F will still be set for security purposes upon reflection." >>>=20 >>> If a reflector wants to tell an Initiator to slow down, it would >>>simply need to >>> inject an additional packet (perhaps a DoS on its own, so should be >>> rate-limited) with the P bit set. This is effectively the "dueling >>>poll" >>> scenario that had popped up much earlier in standardization. >>>=20 >>> -- Jeff >>=20 > From nobody Mon Mar 17 03:56:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB35C1A03DB for ; Mon, 17 Mar 2014 03:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_PdwblntxMB for ; Mon, 17 Mar 2014 03:56:30 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id D074F1A03D9 for ; Mon, 17 Mar 2014 03:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16905; q=dns/txt; s=iport; t=1395053782; x=1396263382; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=3IPyo3/hkYjtr4N5Fj/p6XRuqKRm/YjFhfdsMFZ/GLU=; b=DpUvYOHeT6t39j77iJLuWinw18vcxdgkhXAe60OoCCl8+cBNayYeu74J iz1Yx5V0XXhypxHWgkSGtDM+ug4wP8KjL6jYLGMVHkIjXku613XcUTj9/ 8h5sh8Vjrb16pBeUw7xf80ACH5ieu+PeFxDZ0MlScZUT7e2YVMXBmjMPC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAILUJlOtJXG+/2dsb2JhbABZgkJEgRKpcpgOgRkWdIIlAQEBBHkMBgEIEQMBAQEoJgIRFAkIAgQBDQWHZQMRyw0Nhy8XjFCBNgoHAT8RBwaEMgSOdIdlgW2MZ4VIgy2BaQkXIg X-IronPort-AV: E=Sophos; i="4.97,669,1389744000"; d="scan'208,217"; a="27994528" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 17 Mar 2014 10:56:21 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2HAuLUM029788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 10:56:21 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 05:56:21 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Sam Aldrin , "Nobo Akiya (nobo)" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgA= Date: Mon, 17 Mar 2014 10:56:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF4CCD271C83Dmmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qYlgsjxu05B1gbatFAqLIw9TVnY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 10:56:33 -0000 --_000_CF4CCD271C83Dmmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, >From the discussions I understand that the following is the sequence being = discussed: (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) Normal Sequence A to B: [p=3D0,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packets Timer negotiation (ack) A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll Timer negotiation (nack) Dueling poll A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll We have a few questions: 1. In the above P/F approach, we are still overloading the interpretatio= n of 'F' bit. In our view this is same as re-interpreting/overloading 'D' b= it. Don't the same arguments that we used against 'D' bit apply here too? 2. Most of the H/W based implementations use P/F bits to punt the receiv= ed packets to S/W . Overloading P/F bits may impact H/W based implementatio= ns depending on these bits. 3. 'F' bit itself is now ambiguous. Implementations will have to go thro= ugh extra logic to process a packet with 'F' bit set I.e to know if it is a= reflected packet or a response to the poll that is initiated. Thanks Regards Mallik From: Sam Aldrin > Date: Friday 14 March 2014 4:17 AM To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Comments inline. Sent from my iPad On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: Hi Jeff, Marc, BFDers, [Jeff wrote] So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." This is certainly lesser evil than other evil ideas (especially v2 BFD), I= 'll take it :) S-BFD authors/collaborators & BFDers, comments? (speak now or forever hold your peace) Catching on this long email thread, finally. I too prefer not going v2 way, as it creates more complexity or open up man= y more issues. P/F bits as suggested by Jeff is a good option and we should use it. Base d= ocument should document on how those bits should be used, that includes any= interval change. [Jeff wrote] If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. So bit it. [Marc wrote] ah well, we simply don't have enough flags in the BFD packet. You are sure we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) I am very sure :) [Marc wrote] But seriously: as the S-BFD sender is effectively talking to itself you do = not need P/F to synchronize two systems. The reflector can simply set the Required Min RX Interval as it wants and the S-BFD sender adjusts. True that's definitely a possibility, but someone will surely argue that ch= anging interval w/o presence of P bit will violate RFC5880. If it deviates from the way the P bit is presently being used, true. But if= S-BFD could set rx interval differently to regular BFD as long as we docum= ent it right, we wouldn't be violating RFC5880, IMO. Do you think RFC is r= igid about interval change? [Marc wrote] Also: as Jeff mentioned, without any "session state" on the reflector side = it would be difficult to match any received F bit to a particular P sent out? With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector now.= Reflector can still send [P=3D1, F=3D0], but that is one-way-communication= /request. Nod. Sam -Nobo -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, March 13, 2014 4:28 PM To: Nobo Akiya (nobo) Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: I may be mis-remembering the conversation or mis-reading the document, but since the reflector is intended to be stateless why would it expect to receive a Final from the Initiator? It doesn't, reflector doesn't expect F bit (hence best effort). P bit will = alert initiator that parameter has changed (i.e. Required Min RX Interval has changed). Remember that the primary reason for the Required Min RX Interval in regular BFD is that the receiver is also running a timer and will use that = for its state by helping to adjust the sender's speed in a graceful fashion. In this case, graceful is important since only the Initiator cares about th= e actual timing of the packets. And even then, for our original scenario: A---M---B As long as each side doesn't respond to F packets (but sends them), I think we're still good. I think this means you can keep the poll bit idea to hel= p suggest an Initiator to slow down and still prevent DoS. In such a scenari= o, M is injecting packets to A, with or without P, using B's addressing. Withou= t P, A could still respond with F and B would drop it. So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. -- Jeff --_000_CF4CCD271C83Dmmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <19B82DF528D2C243B5D0E730D6716290@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi All,

From the discussions I understand that the following is the sequence b= eing discussed:

(Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector)

Normal Sequence

A to B: [p=3D0,F=3D0] =3D=3D> ping packets
B to A: [p=3D0,F=3D1] =3D=3D> pong packets

Timer negotiation (ack)

A to B: [p=3D1,F=3D0] =3D=3D> ping packets
B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll

Timer negotiation (nack) Dueling poll

A to B: [p=3D1,F=3D0] =3D=3D> ping packets
B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll
B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll

We have a few questions:

  1. In the above P/F approach, we are still overloading the interpretation = of 'F' bit. In our view this is same as re-interpreting/overloading 'D' bit= . Don't the same arguments that we used against 'D' bit apply here too?
  2. Most of the H/W based implementations use P/F bits to punt the receive= d packets to S/W . Overloading P/F bits may impact H/W based implementation= s depending on these bits.
  3. 'F' bit itself is now ambiguous. Impleme= ntations will have to go through extra logic to process a packet with 'F' b= it set I.e to know if it is a reflected packet or a response to the poll th= at is initiated.
 Thanks

Regards
Mallik
From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Friday 14 March 2014 4:17 AM<= br> To: "Nobo Akiya (nobo)" &= lt;nobo@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Comments inline.

Sent from my iPad

On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" <nobo@cisco.com> wrote:
Hi Jeff, Marc, BFDers,
[Jeff wrote]
So, I suppose the suggested addition to the S-BFD logic is "in th= e absence of
a P-bit, F will still be set for security purposes upon reflection.&qu= ot;
This  is certainly lesser evil than other evil ideas (especi= ally v2 BFD), I'll take it :)
S-BFD authors/collaborators & BFDers, comments?
(speak now or forever hold your peace)
Catching on this long email thread, finally.

I too prefer not going v2 way, as it creates more complexity or open u= p many more issues.
P/F bits as suggested by Jeff is a good option and we should use it. B= ase document should document on how those bits should be used, that include= s any interval change.
[Jeff wrote]
If a reflector wants to tell an Initiator to slow down, it would simpl= y need to
inject an additional packet (perhaps a DoS on its own, so should be
rate-limited) with the P bit set.  This is effectively the &= quot;dueling poll"
scenario that had popped up much earlier in standardization.
So bit it.
[Marc wrote]
ah well, we simply don't have enough flags in the BFD packet. You are = sure
we don't want a BFD "v2" to add another 32/64 bit for future= flag use? ;-)
I am very sure :)
[Marc wrote]
But seriously: as the S-BFD sender is effectively talking to itself yo= u do not
need P/F to synchronize two systems. The reflector can simply set the<= /div>
Required Min RX Interval as it wants and the S-BFD sender adjusts.
True that's definitely a possibility, but someone will surely argue th= at changing interval w/o presence of P bit will violate RFC5880.
If it deviates from the way the P bit is presently being used, true. B= ut if S-BFD could set rx interval differently to regular BFD as long as we = document it right, we wouldn't  be violating RFC5880, IMO. Do you= think RFC is rigid about interval change?
[Marc wrote]
Also: as Jeff mentioned, without any "session state" on the = reflector side it
would be difficult to match any received F bit to a particular P sent = out?
With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector= now. Reflector can still send [P=3D1, F=3D0], but that is one-way-communic= ation/request.

Nod.

Sam
-Nobo
-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfr= c.org]
Sent: Thursday, March 13, 2014 4:28 PM
To: Nobo Akiya (nobo)
Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote:=
I may be mis-remembering the conversation or mis-reading the
document, but since the reflector is intended to be stateless why
would it expect to receive a Final from the Initiator?
It doesn't, reflector doesn't expect F bit (hence best effort). P bit = will alert
initiator that parameter has changed (i.e. Required Min RX Interval ha= s
changed).
Remember that the primary reason for the Required Min RX Interval in
regular BFD is that the receiver is also running a timer and will use = that for
its state by helping to adjust the sender's speed in a graceful fashio= n.
In this case, graceful is important since only the Initiator cares abo= ut the
actual timing of the packets.
And even then, for our original scenario:
A---M---B
As long as each side doesn't respond to F packets (but sends them), I = think
we're still good.  I think this means you can keep the poll = bit idea to help
suggest an Initiator to slow down and still prevent DoS.  In= such a scenario, M
is injecting packets to A, with or without P, using B's addressing.&nb= sp; Without P,
A could still respond with F and B would drop it.
So, I suppose the suggested addition to the S-BFD logic is "in th= e absence of
a P-bit, F will still be set for security purposes upon reflection.&qu= ot;
If a reflector wants to tell an Initiator to slow down, it would simpl= y need to
inject an additional packet (perhaps a DoS on its own, so should be
rate-limited) with the P bit set.  This is effectively the &= quot;dueling poll"
scenario that had popped up much earlier in standardization.
-- Jeff


 --_000_CF4CCD271C83Dmmudigonciscocom_-- From nobody Mon Mar 17 04:17:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05E1A03F2 for ; Mon, 17 Mar 2014 04:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2Dk9iyUeQWn for ; Mon, 17 Mar 2014 04:17:06 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2571A03E1 for ; Mon, 17 Mar 2014 04:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37779; q=dns/txt; s=iport; t=1395055018; x=1396264618; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9BwKbB6s97nbY7nQXtzt71joxOxlMMG/f1bsklCsd4k=; b=PD74n+vqps372fTe0WN0dTsC+KSdSC04Bc/bWKHmq/II5ZbKjurLrqif 5UEVlaGxqQauzJGHejY8AQPtQQ7AgXoK/E4EcJgoa4lmLsCTXUh/Pe6Bz SWzwRT6m3XCXG+QatLQnU/4Pr5wiK13wTfUNfDlW9xAztOQujBvexirpJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAEHZJlOtJXG//2dsb2JhbABZgkJEO1epc5gOgRcWdIIlAQEBBC1MDAQCAQgRAwEBAQsWAQYHIREUCQgCBAENBQiHXQMRyxINhy8XjFCBNgoHAR8gEQYBBoMegRQEllmOVIVIgy2BaQkXIg X-IronPort-AV: E=Sophos; i="4.97,669,1389744000"; d="scan'208,217"; a="28009377" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-4.cisco.com with ESMTP; 17 Mar 2014 11:16:57 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2HBGv6C012489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 11:16:57 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 06:16:57 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "MALLIK MUDIGONDA (mmudigon)" , Sam Aldrin , "Nobo Akiya (nobo)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34A== Date: Mon, 17 Mar 2014 11:16:57 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.252] Content-Type: multipart/alternative; boundary="_000_315041E4211CB84E86EF7C25A2AB583D339D408Fxmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dv1bTGSYirOvRPTqAI9MsF_qJuk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 11:17:09 -0000 --_000_315041E4211CB84E86EF7C25A2AB583D339D408Fxmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, One comment inlined with GVP>. Thanks Prasad From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Monday, March 17, 2014 4:26 PM To: Sam Aldrin; Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi All, >From the discussions I understand that the following is the sequence being = discussed: (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) Normal Sequence A to B: [p=3D0,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packets Timer negotiation (ack) A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll Timer negotiation (nack) Dueling poll A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll We have a few questions: 1. In the above P/F approach, we are still overloading the interpretatio= n of 'F' bit. In our view this is same as re-interpreting/overloading 'D' b= it. Don't the same arguments that we used against 'D' bit apply here too? 2. Most of the H/W based implementations use P/F bits to punt the receiv= ed packets to S/W . Overloading P/F bits may impact H/W based implementatio= ns depending on these bits. GVP> Fully agree, I would prefer an option not re-interpreting or overloadi= ng the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are h= ard to change. 1. 'F' bit itself is now ambiguous. Implementations will have to go thro= ugh extra logic to process a packet with 'F' bit set I.e to know if it is a= reflected packet or a response to the poll that is initiated. Thanks Regards Mallik From: Sam Aldrin > Date: Friday 14 March 2014 4:17 AM To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Comments inline. Sent from my iPad On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: Hi Jeff, Marc, BFDers, [Jeff wrote] So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." This is certainly lesser evil than other evil ideas (especially v2 BFD), I= 'll take it :) S-BFD authors/collaborators & BFDers, comments? (speak now or forever hold your peace) Catching on this long email thread, finally. I too prefer not going v2 way, as it creates more complexity or open up man= y more issues. P/F bits as suggested by Jeff is a good option and we should use it. Base d= ocument should document on how those bits should be used, that includes any= interval change. [Jeff wrote] If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. So bit it. [Marc wrote] ah well, we simply don't have enough flags in the BFD packet. You are sure we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) I am very sure :) [Marc wrote] But seriously: as the S-BFD sender is effectively talking to itself you do = not need P/F to synchronize two systems. The reflector can simply set the Required Min RX Interval as it wants and the S-BFD sender adjusts. True that's definitely a possibility, but someone will surely argue that ch= anging interval w/o presence of P bit will violate RFC5880. If it deviates from the way the P bit is presently being used, true. But if= S-BFD could set rx interval differently to regular BFD as long as we docum= ent it right, we wouldn't be violating RFC5880, IMO. Do you think RFC is r= igid about interval change? [Marc wrote] Also: as Jeff mentioned, without any "session state" on the reflector side = it would be difficult to match any received F bit to a particular P sent out? With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector now.= Reflector can still send [P=3D1, F=3D0], but that is one-way-communication= /request. Nod. Sam -Nobo -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, March 13, 2014 4:28 PM To: Nobo Akiya (nobo) Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: I may be mis-remembering the conversation or mis-reading the document, but since the reflector is intended to be stateless why would it expect to receive a Final from the Initiator? It doesn't, reflector doesn't expect F bit (hence best effort). P bit will = alert initiator that parameter has changed (i.e. Required Min RX Interval has changed). Remember that the primary reason for the Required Min RX Interval in regular BFD is that the receiver is also running a timer and will use that = for its state by helping to adjust the sender's speed in a graceful fashion. In this case, graceful is important since only the Initiator cares about th= e actual timing of the packets. And even then, for our original scenario: A---M---B As long as each side doesn't respond to F packets (but sends them), I think we're still good. I think this means you can keep the poll bit idea to hel= p suggest an Initiator to slow down and still prevent DoS. In such a scenari= o, M is injecting packets to A, with or without P, using B's addressing. Withou= t P, A could still respond with F and B would drop it. So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. -- Jeff --_000_315041E4211CB84E86EF7C25A2AB583D339D408Fxmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

  One comment inline= d with GVP>.

Thanks<= /p>

Prasad<= /p>

 <= /p>

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Monday, March 17, 2014 4:26 PM
To: Sam Aldrin; Nobo Akiya (nobo)
Cc: rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hi All,

 

From the discussions I unders= tand that the following is the sequence being discussed:<= /p>

 

(Initiator)A=3D=3D=3D=3D=3DM= =3D=3D=3D=3D=3DB(Reflector)

 

Normal Sequence

 

A to B: [p=3D0,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0,F=3D1] =3D=3D&= gt; pong packets

 

Timer negotiation (ack)<= /o:p>

 

A to B: [p=3D1,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0,F=3D1] =3D=3D&= gt; pong packet with ack for timer poll

 

Timer negotiation (nack) Duel= ing poll

 

A to B: [p=3D1,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0.F=3D1] =3D=3D&= gt; pong packet with ack for timer poll

B to A: [p=3D1,F=3D0] =3D=3D&= gt; Reflector initiated poll

 

We have a few questions:=

 

  1. In the above P/F approach, we are still overloading the interpre= tation of 'F' bit. In our view this is same as re-interpreting/overloading = 'D' bit. Don't the same arguments that we used against 'D' bit apply here too?
  2. Most of the H/W based implementations use P/F bits to punt the r= eceived packets to S/W . Overloading P/F bits may impact H/W based implemen= tations depending on these bits.

GVP> Fully agree, I would prefer an = option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to change.

  1. 'F' bit itself is now ambiguous. Implementations will have to go= through extra logic to process a packet with 'F' bit set I.e to know if it= is a reflected packet or a response to the poll that is initiated.

 Thanks

 

Regards

Mallik

From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Friday 14 March 2014 4:17 AM
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Comments inline.

 

Sent from my iPad<= /span>

 

On Mar 13, 2014, at 1:48 PM, = "Nobo Akiya (nobo)" <nobo@ci= sco.com> wrote:

Hi Jeff, Marc, BFDers,

[Jeff wrote]

So, I suppose the suggested a= ddition to the S-BFD logic is "in the absence of

a P-bit, F will still be set = for security purposes upon reflection."

This  is certainly = lesser evil than other evil ideas (especially v2 BFD), I'll take it :)=

S-BFD authors/collaborators &= amp; BFDers, comments?

(speak now or forever hold yo= ur peace)

Catching on this long email t= hread, finally.

 

I too prefer not going v2 way= , as it creates more complexity or open up many more issues.

P/F bits as suggested by Jeff= is a good option and we should use it. Base document should document on ho= w those bits should be used, that includes any interval change.

[Jeff wrote]

If a reflector wants to tell = an Initiator to slow down, it would simply need to

inject an additional packet (= perhaps a DoS on its own, so should be

rate-limited) with the P bit = set.  This is effectively the "dueling poll"=

scenario that had popped up m= uch earlier in standardization.

So bit it.<= /p>

[Marc wrote]

ah well, we simply don't have= enough flags in the BFD packet. You are sure

we don't want a BFD "v2&= quot; to add another 32/64 bit for future flag use? ;-)

I am very sure :)<= /span>

[Marc wrote]

But seriously: as the S-BFD s= ender is effectively talking to itself you do not

need P/F to synchronize two s= ystems. The reflector can simply set the

Required Min RX Interval as i= t wants and the S-BFD sender adjusts.

True that's definitely a poss= ibility, but someone will surely argue that changing interval w/o presence = of P bit will violate RFC5880.

If it deviates from the way t= he P bit is presently being used, true. But if S-BFD could set rx interval = differently to regular BFD as long as we document it right, we wouldn't  be violating RFC5880, IMO. Do you think RFC is rigi= d about interval change?

[Marc wrote]

Also: as Jeff mentioned, with= out any "session state" on the reflector side it

would be difficult to match a= ny received F bit to a particular P sent out?

With new proposal by Jeff, [P= =3D0, F=3D1] will be dropped by reflector now. Reflector can still send [P= =3D1, F=3D0], but that is one-way-communication/request.<= /p>

 

Nod.

 

Sam

-Nobo

-----Original Message-----

From: Jeffrey Haas [mailto:jhaas@pfrc.org]

Sent: Thursday, March 13, 201= 4 4:28 PM

To: Nobo Akiya (nobo)

Cc: Jeffrey Haas; Marc Binder= berger; rtg-bfd@ietf.org<= /p>

Subject: Re: Loop Prevention = in S-BFD (draft-akiya-bfd-seamless-base)

On Thu, Mar 13, 2014 at 08:17= :22PM +0000, Nobo Akiya (nobo) wrote:

I may be mis-remembering the = conversation or mis-reading the

document, but since the refle= ctor is intended to be stateless why

would it expect to receive a = Final from the Initiator?

It doesn't, reflector doesn't= expect F bit (hence best effort). P bit will alert

initiator that parameter has = changed (i.e. Required Min RX Interval has

changed).

Remember that the primary rea= son for the Required Min RX Interval in

regular BFD is that the recei= ver is also running a timer and will use that for

its state by helping to adjus= t the sender's speed in a graceful fashion.

In this case, graceful is imp= ortant since only the Initiator cares about the

actual timing of the packets.=

And even then, for our origin= al scenario:

A---M---B

As long as each side doesn't = respond to F packets (but sends them), I think

we're still good.  = I think this means you can keep the poll bit idea to help=

suggest an Initiator to slow = down and still prevent DoS.  In such a scenario, M

is injecting packets to A, wi= th or without P, using B's addressing.  Without P,

A could still respond with F = and B would drop it.

So, I suppose the suggested a= ddition to the S-BFD logic is "in the absence of

a P-bit, F will still be set = for security purposes upon reflection."

If a reflector wants to tell = an Initiator to slow down, it would simply need to

inject an additional packet (= perhaps a DoS on its own, so should be

rate-limited) with the P bit = set.  This is effectively the "dueling poll"=

scenario that had popped up m= uch earlier in standardization.

-- Jeff

 

 

--_000_315041E4211CB84E86EF7C25A2AB583D339D408Fxmbrcdx15ciscoc_-- From nobody Mon Mar 17 05:51:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A712A1A03DD for ; Mon, 17 Mar 2014 05:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-OONrteZcuZ for ; Mon, 17 Mar 2014 05:28:32 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id EB5301A03F7 for ; Mon, 17 Mar 2014 05:28:31 -0700 (PDT) Received: from mail135-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Mon, 17 Mar 2014 12:28:23 +0000 Received: from mail135-ch1 (localhost [127.0.0.1]) by mail135-ch1-R.bigfish.com (Postfix) with ESMTP id 56C482E037A; Mon, 17 Mar 2014 12:28:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371Ic85fh542I1432Idf9I14ffIdb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h9a9j1155h) Received-SPF: pass (mail135-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=santoshpk@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(13464003)(377454003)(35774003)(24454002)(53754006)(76796001)(95666003)(76576001)(76786001)(19300405004)(92566001)(93136001)(90146001)(56816005)(4396001)(47976001)(47736001)(49866001)(50986001)(85306002)(87266001)(2656002)(83072002)(85852003)(15202345003)(87936001)(74316001)(81342001)(16236675002)(81542001)(74876001)(79102001)(74706001)(59766001)(77982001)(33646001)(20776003)(63696002)(74366001)(46102001)(93516002)(86362001)(81686001)(51856001)(15975445006)(81816001)(95416001)(54316002)(80022001)(53806001)(66066001)(80976001)(97186001)(94316002)(97336001)(94946001)(19580405001)(54356001)(19580395003)(76482001)(83322001)(47446002)(74662001)(74502001)(31966008)(561944002)(56776001)(69226001)(65816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB754; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:A60CFEF7.A8EAD591.F0FF716B.42E8EDB1.2065D; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail135-ch1 (localhost.localdomain [127.0.0.1]) by mail135-ch1 (MessageSwitch) id 1395059299805694_22572; Mon, 17 Mar 2014 12:28:19 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail135-ch1.bigfish.com (Postfix) with ESMTP id B2120460051; Mon, 17 Mar 2014 12:28:19 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 17 Mar 2014 12:28:19 +0000 Received: from BLUPR05MB754.namprd05.prod.outlook.com (10.141.208.142) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 17 Mar 2014 12:28:18 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB754.namprd05.prod.outlook.com (10.141.208.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 17 Mar 2014 12:28:17 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.0898.005; Mon, 17 Mar 2014 12:28:16 +0000 From: Santosh P K To: "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" , Sam Aldrin , "Nobo Akiya (nobo)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAEGvwCAAQylgIAAnxaAgALHwACAAAMxgIAAA9AAgAATlACAAAK7gIAAAjcAgAAC5ICAAAXLgIAAITAAgAWCtACAAAXCgIAAEzSQ Date: Mon, 17 Mar 2014 12:28:16 +0000 Message-ID: <5c57314c33bc4993ae14f8c915e7e3f3@BLUPR05MB755.namprd05.prod.outlook.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.15] x-forefront-prvs: 0153A8321A Content-Type: multipart/alternative; boundary="_000_5c57314c33bc4993ae14f8c915e7e3f3BLUPR05MB755namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/pUWMqZRZu2IwL2-VFudlV5B8RDg X-Mailman-Approved-At: Mon, 17 Mar 2014 05:51:40 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 12:28:34 -0000 --_000_5c57314c33bc4993ae14f8c915e7e3f3BLUPR05MB755namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Prasad, >>Most of the H/W based implementations use P/F bits to punt the received p= ackets to S/W . Overloading P/F bits may impact H/W based implementations d= epending on these bits. > GVP> Fully agree, I would prefer an option not re-interpreti= ng or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumpt= ions that are hard to change. This should not be an issue right? We have dedicated UDP port number for S-= BFD. The way a packet is processed is different for S-BFD than regular BFD. Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada Prasad= Govindan (venggovi) Sent: Monday, March 17, 2014 4:47 PM To: MALLIK MUDIGONDA (mmudigon); Sam Aldrin; Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello all, One comment inlined with GVP>. Thanks Prasad From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Monday, March 17, 2014 4:26 PM To: Sam Aldrin; Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi All, >From the discussions I understand that the following is the sequence being = discussed: (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) Normal Sequence A to B: [p=3D0,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packets Timer negotiation (ack) A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll Timer negotiation (nack) Dueling poll A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll We have a few questions: 1. In the above P/F approach, we are still overloading the interpretatio= n of 'F' bit. In our view this is same as re-interpreting/overloading 'D' b= it. Don't the same arguments that we used against 'D' bit apply here too? 2. Most of the H/W based implementations use P/F bits to punt the receiv= ed packets to S/W . Overloading P/F bits may impact H/W based implementatio= ns depending on these bits. GVP> Fully agree, I would prefer an option not re-interpreting or overloadi= ng the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are h= ard to change. 1. 'F' bit itself is now ambiguous. Implementations will have to go thro= ugh extra logic to process a packet with 'F' bit set I.e to know if it is a= reflected packet or a response to the poll that is initiated. Thanks Regards Mallik From: Sam Aldrin > Date: Friday 14 March 2014 4:17 AM To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Comments inline. Sent from my iPad On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: Hi Jeff, Marc, BFDers, [Jeff wrote] So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." This is certainly lesser evil than other evil ideas (especially v2 BFD), I= 'll take it :) S-BFD authors/collaborators & BFDers, comments? (speak now or forever hold your peace) Catching on this long email thread, finally. I too prefer not going v2 way, as it creates more complexity or open up man= y more issues. P/F bits as suggested by Jeff is a good option and we should use it. Base d= ocument should document on how those bits should be used, that includes any= interval change. [Jeff wrote] If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. So bit it. [Marc wrote] ah well, we simply don't have enough flags in the BFD packet. You are sure we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) I am very sure :) [Marc wrote] But seriously: as the S-BFD sender is effectively talking to itself you do = not need P/F to synchronize two systems. The reflector can simply set the Required Min RX Interval as it wants and the S-BFD sender adjusts. True that's definitely a possibility, but someone will surely argue that ch= anging interval w/o presence of P bit will violate RFC5880. If it deviates from the way the P bit is presently being used, true. But if= S-BFD could set rx interval differently to regular BFD as long as we docum= ent it right, we wouldn't be violating RFC5880, IMO. Do you think RFC is r= igid about interval change? [Marc wrote] Also: as Jeff mentioned, without any "session state" on the reflector side = it would be difficult to match any received F bit to a particular P sent out? With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector now.= Reflector can still send [P=3D1, F=3D0], but that is one-way-communication= /request. Nod. Sam -Nobo -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, March 13, 2014 4:28 PM To: Nobo Akiya (nobo) Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: I may be mis-remembering the conversation or mis-reading the document, but since the reflector is intended to be stateless why would it expect to receive a Final from the Initiator? It doesn't, reflector doesn't expect F bit (hence best effort). P bit will = alert initiator that parameter has changed (i.e. Required Min RX Interval has changed). Remember that the primary reason for the Required Min RX Interval in regular BFD is that the receiver is also running a timer and will use that = for its state by helping to adjust the sender's speed in a graceful fashion. In this case, graceful is important since only the Initiator cares about th= e actual timing of the packets. And even then, for our original scenario: A---M---B As long as each side doesn't respond to F packets (but sends them), I think we're still good. I think this means you can keep the poll bit idea to hel= p suggest an Initiator to slow down and still prevent DoS. In such a scenari= o, M is injecting packets to A, with or without P, using B's addressing. Withou= t P, A could still respond with F and B would drop it. So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. -- Jeff --_000_5c57314c33bc4993ae14f8c915e7e3f3BLUPR05MB755namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Prasad,

 

>>Most of the H/W based implementations use P/= F bits to punt the received packets to S/W . Overloading P/F bits may impac= t H/W based implementations depending on these bits.

      &nb= sp;      > GVP> Fully agree, I would prefer = an option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to= change.

This should not be an issue right? We h= ave dedicated UDP port number for S-BFD. The way a packet is processed is different for S-BFD than regular BFD.

 

Thanks

Santosh P K

From: Rtg-bf= d [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada Prasad Govindan (venggovi)
Sent: Monday, March 17, 2014 4:47 PM
To: MALLIK MUDIGONDA (mmudigon); Sam Aldrin; Nobo Akiya (nobo)
Cc: rtg-bfd@ietf.org
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hello all,

  One comment inline= d with GVP>.

Thanks<= /p>

Prasad<= /p>

 <= /p>

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Monday, March 17, 2014 4:26 PM
To: Sam Aldrin; Nobo Akiya (nobo)
Cc: rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hi All,

 

From the discussions I unders= tand that the following is the sequence being discussed:<= /p>

 

(Initiator)A=3D=3D=3D=3D=3DM= =3D=3D=3D=3D=3DB(Reflector)

 

Normal Sequence

 

A to B: [p=3D0,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0,F=3D1] =3D=3D&= gt; pong packets

 

Timer negotiation (ack)<= /o:p>

 

A to B: [p=3D1,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0,F=3D1] =3D=3D&= gt; pong packet with ack for timer poll

 

Timer negotiation (nack) Duel= ing poll

 

A to B: [p=3D1,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0.F=3D1] =3D=3D&= gt; pong packet with ack for timer poll

B to A: [p=3D1,F=3D0] =3D=3D&= gt; Reflector initiated poll

 

We have a few questions:=

 

  1. In the above P/F approach, we are still overloading the interpre= tation of 'F' bit. In our view this is same as re-interpreting/overloading = 'D' bit. Don't the same arguments that we used against 'D' bit apply here too?
  2. Most of the H/W based implementations use P/F bits to punt the r= eceived packets to S/W . Overloading P/F bits may impact H/W based implemen= tations depending on these bits.

GVP> Fully agree, I would prefer an = option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to change.

  1. 'F' bit itself is now ambiguous. Implementations will have to go= through extra logic to process a packet with 'F' bit set I.e to know if it= is a reflected packet or a response to the poll that is initiated.

 Thanks

 

Regards

Mallik

From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Friday 14 March 2014 4:17 AM
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Comments inline.

 

Sent from my iPad<= /span>

 

On Mar 13, 2014, at 1:48 PM, = "Nobo Akiya (nobo)" <nobo@ci= sco.com> wrote:

Hi Jeff, Marc, BFDers,

[Jeff wrote]

So, I suppose the suggested a= ddition to the S-BFD logic is "in the absence of

a P-bit, F will still be set = for security purposes upon reflection."

This  is certainly = lesser evil than other evil ideas (especially v2 BFD), I'll take it :)=

S-BFD authors/collaborators &= amp; BFDers, comments?

(speak now or forever hold yo= ur peace)

Catching on this long email t= hread, finally.

 

I too prefer not going v2 way= , as it creates more complexity or open up many more issues.

P/F bits as suggested by Jeff= is a good option and we should use it. Base document should document on ho= w those bits should be used, that includes any interval change.

[Jeff wrote]

If a reflector wants to tell = an Initiator to slow down, it would simply need to

inject an additional packet (= perhaps a DoS on its own, so should be

rate-limited) with the P bit = set.  This is effectively the "dueling poll"=

scenario that had popped up m= uch earlier in standardization.

So bit it.<= /p>

[Marc wrote]

ah well, we simply don't have= enough flags in the BFD packet. You are sure

we don't want a BFD "v2&= quot; to add another 32/64 bit for future flag use? ;-)

I am very sure :)<= /span>

[Marc wrote]

But seriously: as the S-BFD s= ender is effectively talking to itself you do not

need P/F to synchronize two s= ystems. The reflector can simply set the

Required Min RX Interval as i= t wants and the S-BFD sender adjusts.

True that's definitely a poss= ibility, but someone will surely argue that changing interval w/o presence = of P bit will violate RFC5880.

If it deviates from the way t= he P bit is presently being used, true. But if S-BFD could set rx interval = differently to regular BFD as long as we document it right, we wouldn't  be violating RFC5880, IMO. Do you think RFC is rigi= d about interval change?

[Marc wrote]

Also: as Jeff mentioned, with= out any "session state" on the reflector side it

would be difficult to match a= ny received F bit to a particular P sent out?

With new proposal by Jeff, [P= =3D0, F=3D1] will be dropped by reflector now. Reflector can still send [P= =3D1, F=3D0], but that is one-way-communication/request.<= /p>

 

Nod.

 

Sam

-Nobo

-----Original Message-----

From: Jeffrey Haas [mailto:jhaas@pfrc.org]

Sent: Thursday, March 13, 201= 4 4:28 PM

To: Nobo Akiya (nobo)

Cc: Jeffrey Haas; Marc Binder= berger; rtg-bfd@ietf.org<= /p>

Subject: Re: Loop Prevention = in S-BFD (draft-akiya-bfd-seamless-base)

On Thu, Mar 13, 2014 at 08:17= :22PM +0000, Nobo Akiya (nobo) wrote:

I may be mis-remembering the = conversation or mis-reading the

document, but since the refle= ctor is intended to be stateless why

would it expect to receive a = Final from the Initiator?

It doesn't, reflector doesn't= expect F bit (hence best effort). P bit will alert

initiator that parameter has = changed (i.e. Required Min RX Interval has

changed).

Remember that the primary rea= son for the Required Min RX Interval in

regular BFD is that the recei= ver is also running a timer and will use that for

its state by helping to adjus= t the sender's speed in a graceful fashion.

In this case, graceful is imp= ortant since only the Initiator cares about the

actual timing of the packets.=

And even then, for our origin= al scenario:

A---M---B

As long as each side doesn't = respond to F packets (but sends them), I think

we're still good.  = I think this means you can keep the poll bit idea to help=

suggest an Initiator to slow = down and still prevent DoS.  In such a scenario, M

is injecting packets to A, wi= th or without P, using B's addressing.  Without P,

A could still respond with F = and B would drop it.

So, I suppose the suggested a= ddition to the S-BFD logic is "in the absence of

a P-bit, F will still be set = for security purposes upon reflection."

If a reflector wants to tell = an Initiator to slow down, it would simply need to

inject an additional packet (= perhaps a DoS on its own, so should be

rate-limited) with the P bit = set.  This is effectively the "dueling poll"=

scenario that had popped up m= uch earlier in standardization.

-- Jeff

 

 

--_000_5c57314c33bc4993ae14f8c915e7e3f3BLUPR05MB755namprd05pro_-- From nobody Mon Mar 17 08:27:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01601A0427 for ; Mon, 17 Mar 2014 08:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4g2pmWHUhnJ for ; Mon, 17 Mar 2014 08:19:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id B14401A0413 for ; Mon, 17 Mar 2014 08:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47745; q=dns/txt; s=iport; t=1395069565; x=1396279165; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0hhBGMcHAKoXX3Lws4/wyC0oEccAsgADrE/xXQ8dsQk=; b=JZewNo9bpof/kObaU+5tWMWdu1MehrOgIecplDdNg7wAMxI+8uC5OXHW K7nUtg8p2bC9UkbGTAsqCAAxPWi8ysGCQYD9kOcoGG9MqLGth8gJrrZC+ t69jDKXiCJMvRQK0nhUUpDjSZMkjRQbvT8HDgljYm7qhUuamx905M8seP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAMARJ1OtJXG+/2dsb2JhbABZgkJEO1epdJgOgRoWdIIlAQEBAwEtTAUHBAIBCBEDAQEBCxYBBgchERQJCAIEAQ0FCIddAwkIyz8Nhn4XjFCBNgoHAR8gEQYBBoMegRQEllmOVIVIgy2BaQkXIg X-IronPort-AV: E=Sophos; i="4.97,670,1389744000"; d="scan'208,217"; a="28054104" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-3.cisco.com with ESMTP; 17 Mar 2014 15:19:24 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2HFJOgD024164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 15:19:24 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 10:19:24 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Santosh P K , "MALLIK MUDIGONDA (mmudigon)" , Sam Aldrin , "Nobo Akiya (nobo)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//ErQAgAAk6mA= Date: Mon, 17 Mar 2014 15:19:23 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D339D431D@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <5c57314c33bc4993ae14f8c915e7e3f3@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <5c57314c33bc4993ae14f8c915e7e3f3@BLUPR05MB755.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.40.243] Content-Type: multipart/alternative; boundary="_000_315041E4211CB84E86EF7C25A2AB583D339D431Dxmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-xMBDuppGA4kZ0kU-iXuoD9f120 X-Mailman-Approved-At: Mon, 17 Mar 2014 08:27:32 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 15:19:35 -0000 --_000_315041E4211CB84E86EF7C25A2AB583D339D431Dxmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Santosh, Please see inline GVP2>. Thanks Prasad From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Monday, March 17, 2014 5:58 PM To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Sam Al= drin; Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello Prasad, >>Most of the H/W based implementations use P/F bits to punt the received p= ackets to S/W . Overloading P/F bits may impact H/W based implementations d= epending on these bits. > GVP> Fully agree, I would prefer an option not re-interpreti= ng or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumpt= ions that are hard to change. This should not be an issue right? We have dedicated UDP port number for S-= BFD. The way a packet is processed is different for S-BFD than regular BFD. GVP2>While I agree on the destination port value, the simpler the flags/ cr= iteria for taking decisions the better especially given the tight time budg= ets of BFD. Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada Prasad= Govindan (venggovi) Sent: Monday, March 17, 2014 4:47 PM To: MALLIK MUDIGONDA (mmudigon); Sam Aldrin; Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello all, One comment inlined with GVP>. Thanks Prasad From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Monday, March 17, 2014 4:26 PM To: Sam Aldrin; Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi All, >From the discussions I understand that the following is the sequence being = discussed: (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) Normal Sequence A to B: [p=3D0,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packets Timer negotiation (ack) A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll Timer negotiation (nack) Dueling poll A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll We have a few questions: 1. In the above P/F approach, we are still overloading the interpretatio= n of 'F' bit. In our view this is same as re-interpreting/overloading 'D' b= it. Don't the same arguments that we used against 'D' bit apply here too? 2. Most of the H/W based implementations use P/F bits to punt the receiv= ed packets to S/W . Overloading P/F bits may impact H/W based implementatio= ns depending on these bits. GVP> Fully agree, I would prefer an option not re-interpreting or overloadi= ng the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are h= ard to change. 1. 'F' bit itself is now ambiguous. Implementations will have to go thro= ugh extra logic to process a packet with 'F' bit set I.e to know if it is a= reflected packet or a response to the poll that is initiated. Thanks Regards Mallik From: Sam Aldrin > Date: Friday 14 March 2014 4:17 AM To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Comments inline. Sent from my iPad On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: Hi Jeff, Marc, BFDers, [Jeff wrote] So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." This is certainly lesser evil than other evil ideas (especially v2 BFD), I= 'll take it :) S-BFD authors/collaborators & BFDers, comments? (speak now or forever hold your peace) Catching on this long email thread, finally. I too prefer not going v2 way, as it creates more complexity or open up man= y more issues. P/F bits as suggested by Jeff is a good option and we should use it. Base d= ocument should document on how those bits should be used, that includes any= interval change. [Jeff wrote] If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. So bit it. [Marc wrote] ah well, we simply don't have enough flags in the BFD packet. You are sure we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) I am very sure :) [Marc wrote] But seriously: as the S-BFD sender is effectively talking to itself you do = not need P/F to synchronize two systems. The reflector can simply set the Required Min RX Interval as it wants and the S-BFD sender adjusts. True that's definitely a possibility, but someone will surely argue that ch= anging interval w/o presence of P bit will violate RFC5880. If it deviates from the way the P bit is presently being used, true. But if= S-BFD could set rx interval differently to regular BFD as long as we docum= ent it right, we wouldn't be violating RFC5880, IMO. Do you think RFC is r= igid about interval change? [Marc wrote] Also: as Jeff mentioned, without any "session state" on the reflector side = it would be difficult to match any received F bit to a particular P sent out? With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector now.= Reflector can still send [P=3D1, F=3D0], but that is one-way-communication= /request. Nod. Sam -Nobo -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, March 13, 2014 4:28 PM To: Nobo Akiya (nobo) Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: I may be mis-remembering the conversation or mis-reading the document, but since the reflector is intended to be stateless why would it expect to receive a Final from the Initiator? It doesn't, reflector doesn't expect F bit (hence best effort). P bit will = alert initiator that parameter has changed (i.e. Required Min RX Interval has changed). Remember that the primary reason for the Required Min RX Interval in regular BFD is that the receiver is also running a timer and will use that = for its state by helping to adjust the sender's speed in a graceful fashion. In this case, graceful is important since only the Initiator cares about th= e actual timing of the packets. And even then, for our original scenario: A---M---B As long as each side doesn't respond to F packets (but sends them), I think we're still good. I think this means you can keep the poll bit idea to hel= p suggest an Initiator to slow down and still prevent DoS. In such a scenari= o, M is injecting packets to A, with or without P, using B's addressing. Withou= t P, A could still respond with F and B would drop it. So, I suppose the suggested addition to the S-BFD logic is "in the absence = of a P-bit, F will still be set for security purposes upon reflection." If a reflector wants to tell an Initiator to slow down, it would simply nee= d to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. -- Jeff --_000_315041E4211CB84E86EF7C25A2AB583D339D431Dxmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Santosh,=

  Please see inline = GVP2>.

Thanks<= /p>

Prasad<= /p>

 <= /p>

From: Santosh = P K [mailto:santoshpk@juniper.net]
Sent: Monday, March 17, 2014 5:58 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon);= Sam Aldrin; Nobo Akiya (nobo)
Cc: rtg-bfd@ietf.org
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hello Prasad,

 

>>Most of the H/W based implementations use P/= F bits to punt the received packets to S/W . Overloading P/F bits may impac= t H/W based implementations depending on these bits.

      &nb= sp;      > GVP> Fully agree, I would prefer = an option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to= change.

This should not be an issue right? We h= ave dedicated UDP port number for S-BFD. The way a packet is processed is different for S-BFD than regular BFD.

GVP2>While I agree on the destinatio= n port value, the simpler the flags/ criteria for taking decisions the better especially given the tight time budgets of BFD.

Thanks

Santosh P K

From: Rtg-bf= d [mailto:rtg-bfd-bounces@ietf.= org] On Behalf Of Vengada Prasad Govindan (venggovi)
Sent: Monday, March 17, 2014 4:47 PM
To: MALLIK MUDIGONDA (mmudigon); Sam Aldrin; Nobo Akiya (nobo)
Cc: rtg-bfd@ietf.org
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hello all,

  One comment inline= d with GVP>.

Thanks<= /p>

Prasad<= /p>

 <= /p>

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Monday, March 17, 2014 4:26 PM
To: Sam Aldrin; Nobo Akiya (nobo)
Cc: rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Hi All,

 

From the discussions I unders= tand that the following is the sequence being discussed:<= /p>

 

(Initiator)A=3D=3D=3D=3D=3DM= =3D=3D=3D=3D=3DB(Reflector)

 

Normal Sequence

 

A to B: [p=3D0,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0,F=3D1] =3D=3D&= gt; pong packets

 

Timer negotiation (ack)<= /o:p>

 

A to B: [p=3D1,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0,F=3D1] =3D=3D&= gt; pong packet with ack for timer poll

 

Timer negotiation (nack) Duel= ing poll

 

A to B: [p=3D1,F=3D0] =3D=3D&= gt; ping packets

B to A: [p=3D0.F=3D1] =3D=3D&= gt; pong packet with ack for timer poll

B to A: [p=3D1,F=3D0] =3D=3D&= gt; Reflector initiated poll

 

We have a few questions:=

 

  1. In the above P/F approach, we are still overloading the interpre= tation of 'F' bit. In our view this is same as re-interpreting/overloading = 'D' bit. Don't the same arguments that we used against 'D' bit apply here too?
  2. Most of the H/W based implementations use P/F bits to punt the r= eceived packets to S/W . Overloading P/F bits may impact H/W based implemen= tations depending on these bits.

GVP> Fully agree, I would prefer an = option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to change.

  1. 'F' bit itself is now ambiguous. Implementations will have to go= through extra logic to process a packet with 'F' bit set I.e to know if it= is a reflected packet or a response to the poll that is initiated.

 Thanks

 

Regards

Mallik

From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Friday 14 March 2014 4:17 AM
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= )

 

Comments inline.

 

Sent from my iPad<= /span>

 

On Mar 13, 2014, at 1:48 PM, = "Nobo Akiya (nobo)" <nobo@ci= sco.com> wrote:

Hi Jeff, Marc, BFDers,

[Jeff wrote]

So, I suppose the suggested a= ddition to the S-BFD logic is "in the absence of

a P-bit, F will still be set = for security purposes upon reflection."

This  is certainly = lesser evil than other evil ideas (especially v2 BFD), I'll take it :)=

S-BFD authors/collaborators &= amp; BFDers, comments?

(speak now or forever hold yo= ur peace)

Catching on this long email t= hread, finally.

 

I too prefer not going v2 way= , as it creates more complexity or open up many more issues.

P/F bits as suggested by Jeff= is a good option and we should use it. Base document should document on ho= w those bits should be used, that includes any interval change.

[Jeff wrote]

If a reflector wants to tell = an Initiator to slow down, it would simply need to

inject an additional packet (= perhaps a DoS on its own, so should be

rate-limited) with the P bit = set.  This is effectively the "dueling poll"=

scenario that had popped up m= uch earlier in standardization.

So bit it.<= /p>

[Marc wrote]

ah well, we simply don't have= enough flags in the BFD packet. You are sure

we don't want a BFD "v2&= quot; to add another 32/64 bit for future flag use? ;-)

I am very sure :)<= /span>

[Marc wrote]

But seriously: as the S-BFD s= ender is effectively talking to itself you do not

need P/F to synchronize two s= ystems. The reflector can simply set the

Required Min RX Interval as i= t wants and the S-BFD sender adjusts.

True that's definitely a poss= ibility, but someone will surely argue that changing interval w/o presence = of P bit will violate RFC5880.

If it deviates from the way t= he P bit is presently being used, true. But if S-BFD could set rx interval = differently to regular BFD as long as we document it right, we wouldn't  be violating RFC5880, IMO. Do you think RFC is rigi= d about interval change?

[Marc wrote]

Also: as Jeff mentioned, with= out any "session state" on the reflector side it

would be difficult to match a= ny received F bit to a particular P sent out?

With new proposal by Jeff, [P= =3D0, F=3D1] will be dropped by reflector now. Reflector can still send [P= =3D1, F=3D0], but that is one-way-communication/request.<= /p>

 

Nod.

 

Sam

-Nobo

-----Original Message-----

From: Jeffrey Haas [mailto:jhaas@pfrc.org]

Sent: Thursday, March 13, 201= 4 4:28 PM

To: Nobo Akiya (nobo)

Cc: Jeffrey Haas; Marc Binder= berger; rtg-bfd@ietf.org<= /p>

Subject: Re: Loop Prevention = in S-BFD (draft-akiya-bfd-seamless-base)

On Thu, Mar 13, 2014 at 08:17= :22PM +0000, Nobo Akiya (nobo) wrote:

I may be mis-remembering the = conversation or mis-reading the

document, but since the refle= ctor is intended to be stateless why

would it expect to receive a = Final from the Initiator?

It doesn't, reflector doesn't= expect F bit (hence best effort). P bit will alert

initiator that parameter has = changed (i.e. Required Min RX Interval has

changed).

Remember that the primary rea= son for the Required Min RX Interval in

regular BFD is that the recei= ver is also running a timer and will use that for

its state by helping to adjus= t the sender's speed in a graceful fashion.

In this case, graceful is imp= ortant since only the Initiator cares about the

actual timing of the packets.=

And even then, for our origin= al scenario:

A---M---B

As long as each side doesn't = respond to F packets (but sends them), I think

we're still good.  = I think this means you can keep the poll bit idea to help=

suggest an Initiator to slow = down and still prevent DoS.  In such a scenario, M

is injecting packets to A, wi= th or without P, using B's addressing.  Without P,

A could still respond with F = and B would drop it.

So, I suppose the suggested a= ddition to the S-BFD logic is "in the absence of

a P-bit, F will still be set = for security purposes upon reflection."

If a reflector wants to tell = an Initiator to slow down, it would simply need to

inject an additional packet (= perhaps a DoS on its own, so should be

rate-limited) with the P bit = set.  This is effectively the "dueling poll"=

scenario that had popped up m= uch earlier in standardization.

-- Jeff

 

 

--_000_315041E4211CB84E86EF7C25A2AB583D339D431Dxmbrcdx15ciscoc_-- From nobody Mon Mar 17 10:36:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA5E1A0454 for ; Mon, 17 Mar 2014 10:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOL095ViLIkO for ; Mon, 17 Mar 2014 10:36:43 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2461A0449 for ; Mon, 17 Mar 2014 10:36:42 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 55CF72AA0F; Mon, 17 Mar 2014 17:36:31 +0000 (GMT) Date: Mon, 17 Mar 2014 10:36:30 -0700 From: Marc Binderberger To: Vengada Prasad Govindan (venggovi) , MALLIK MUDIGONDA (mmudigon) Message-ID: <20140317103630501812.259d0463@sniff.de> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/X47w11vFEmjFehkB4pG71K1P50c Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 17:36:46 -0000 Hello Mallik and Prasad, > 1. In the above P/F approach, we are still overloading the > interpretation of 'F' bit. In our view this is same as > re-interpreting/overloading 'D' bit. Don't the same arguments that we > used against 'D' bit apply here too? what we discussed about the "D" bit was more on a formal level. For "D" is would be a replacement of what it means in RFC5880 and this is formally kind of a no-no. At least difficult to change. The P/F bit use for S-BFD should, as far as I can see, work smoothly with the existing RFC5880 interpretation. Receiving F-bit set while you are not in a Poll sequence anymore is what existing implementations - which we want to re-use largely on the S-BFD originator side - must support anyway. > 2. Most of the H/W based implementations use P/F bits to punt the > received packets to S/W . Overloading P/F bits may impact H/W based > implementations depending on these bits. > GVP> Fully agree, I would prefer an option not re-interpreting or > overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > assumptions that are hard to change. Thanks for your feedback on this aspect :-) I don't have any good answer here. It would mean on the S-BFD originator side the hw needs a differentiation based on the UDP port instead of simply re-using the existing packet I/O. Or it needs at least a knob to suppress this F-bit punting (which potentially breaks other things). > 3. 'F' bit itself is now ambiguous. Implementations will have to go > through extra logic to process a packet with 'F' bit set I.e to know > if it is a reflected packet or a response to the poll that is > initiated. Don't see that. The only difference it to drop F-bit packets when you are about to reflect them - but the reflector is different code/hw anyway. Otherwise as mentioned above you have already today the situation of receiving F-bit packets while your are not in a Poll sequence (anymore). sigh, this kind of re-using a protocol always has risks and personally I still think we should introduce v2 BFD with 32 or 64 more bits in an otherwise unchanged header and stop spending time on these "clever protocol tricks". But then we won't proceed with S-BFD anymore and have long discussions about the new BFD v2 packet (risk of another "IPv6" with an uber-engineered protocol). So I understand nobody is keen on the v2 topic :-) Really not any good answer from my side other than we may have to look further for something else to "overload". Regards, Marc On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) wrote: > Hello all, > One comment inlined with GVP>. > Thanks > Prasad > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > MUDIGONDA (mmudigon) > Sent: Monday, March 17, 2014 4:26 PM > To: Sam Aldrin; Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > Hi All, > > From the discussions I understand that the following is the sequence > being discussed: > > (Initiator)A=====M=====B(Reflector) > > Normal Sequence > > A to B: [p=0,F=0] ==> ping packets > B to A: [p=0,F=1] ==> pong packets > > Timer negotiation (ack) > > A to B: [p=1,F=0] ==> ping packets > B to A: [p=0,F=1] ==> pong packet with ack for timer poll > > Timer negotiation (nack) Dueling poll > > A to B: [p=1,F=0] ==> ping packets > B to A: [p=0.F=1] ==> pong packet with ack for timer poll > B to A: [p=1,F=0] ==> Reflector initiated poll > > We have a few questions: > > 1. In the above P/F approach, we are still overloading the > interpretation of 'F' bit. In our view this is same as > re-interpreting/overloading 'D' bit. Don't the same arguments that we > used against 'D' bit apply here too? > 2. Most of the H/W based implementations use P/F bits to punt the > received packets to S/W . Overloading P/F bits may impact H/W based > implementations depending on these bits. > GVP> Fully agree, I would prefer an option not re-interpreting or > overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > assumptions that are hard to change. > 3. 'F' bit itself is now ambiguous. Implementations will have to go > through extra logic to process a packet with 'F' bit set I.e to know > if it is a reflected packet or a response to the poll that is > initiated. > Thanks > > Regards > Mallik > From: Sam Aldrin > Date: Friday 14 March 2014 4:17 AM > To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > Comments inline. > > Sent from my iPad > >> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" wrote: >> Hi Jeff, Marc, BFDers, >> [Jeff wrote] >>> So, I suppose the suggested addition to the S-BFD logic is "in the >>> absence of >>> a P-bit, F will still be set for security purposes upon reflection." >> This is certainly lesser evil than other evil ideas (especially v2 >> BFD), I'll take it :) >> S-BFD authors/collaborators & BFDers, comments? >> (speak now or forever hold your peace) > Catching on this long email thread, finally. > > I too prefer not going v2 way, as it creates more complexity or open > up many more issues. > P/F bits as suggested by Jeff is a good option and we should use it. > Base document should document on how those bits should be used, that > includes any interval change. >> [Jeff wrote] >>> If a reflector wants to tell an Initiator to slow down, it would >>> simply need to >>> inject an additional packet (perhaps a DoS on its own, so should be >>> rate-limited) with the P bit set. This is effectively the "dueling poll" >>> scenario that had popped up much earlier in standardization. >> So bit it. >> [Marc wrote] >>> ah well, we simply don't have enough flags in the BFD packet. You are sure >>> we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) >> I am very sure :) >> [Marc wrote] >>> But seriously: as the S-BFD sender is effectively talking to itself >>> you do not >>> need P/F to synchronize two systems. The reflector can simply set the >>> Required Min RX Interval as it wants and the S-BFD sender adjusts. >> True that's definitely a possibility, but someone will surely argue >> that changing interval w/o presence of P bit will violate RFC5880. > If it deviates from the way the P bit is presently being used, true. > But if S-BFD could set rx interval differently to regular BFD as long > as we document it right, we wouldn't be violating RFC5880, IMO. Do > you think RFC is rigid about interval change? >> [Marc wrote] >>> Also: as Jeff mentioned, without any "session state" on the >>> reflector side it >>> would be difficult to match any received F bit to a particular P sent out? >> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector >> now. Reflector can still send [P=1, F=0], but that is >> one-way-communication/request. > > Nod. > > Sam >> -Nobo >>> -----Original Message----- >>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>> Sent: Thursday, March 13, 2014 4:28 PM >>> To: Nobo Akiya (nobo) >>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>>> I may be mis-remembering the conversation or mis-reading the >>>>> document, but since the reflector is intended to be stateless why >>>>> would it expect to receive a Final from the Initiator? >>>> It doesn't, reflector doesn't expect F bit (hence best effort). P >>>> bit will alert >>> initiator that parameter has changed (i.e. Required Min RX Interval has >>> changed). >>> Remember that the primary reason for the Required Min RX Interval in >>> regular BFD is that the receiver is also running a timer and will >>> use that for >>> its state by helping to adjust the sender's speed in a graceful fashion. >>> In this case, graceful is important since only the Initiator cares >>> about the >>> actual timing of the packets. >>> And even then, for our original scenario: >>> A---M---B >>> As long as each side doesn't respond to F packets (but sends them), >>> I think >>> we're still good. I think this means you can keep the poll bit >>> idea to help >>> suggest an Initiator to slow down and still prevent DoS. In such a >>> scenario, M >>> is injecting packets to A, with or without P, using B's >>> addressing. Without P, >>> A could still respond with F and B would drop it. >>> So, I suppose the suggested addition to the S-BFD logic is "in the >>> absence of >>> a P-bit, F will still be set for security purposes upon reflection." >>> If a reflector wants to tell an Initiator to slow down, it would >>> simply need to >>> inject an additional packet (perhaps a DoS on its own, so should be >>> rate-limited) with the P bit set. This is effectively the "dueling poll" >>> scenario that had popped up much earlier in standardization. >>> -- Jeff >> > > From nobody Mon Mar 17 11:30:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2C61A02FB for ; Mon, 17 Mar 2014 11:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pw3HjjoO6MJ for ; Mon, 17 Mar 2014 11:30:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 61F1E1A044D for ; Mon, 17 Mar 2014 11:30:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B405C3EF; Mon, 17 Mar 2014 14:29:52 -0400 (EDT) Date: Mon, 17 Mar 2014 14:29:52 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Message-ID: <20140317182952.GB13937@pfrc> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140317103630501812.259d0463@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6BRj0EAM_ttM5JUb734uVNxd9Rc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 18:30:02 -0000 On Mon, Mar 17, 2014 at 10:36:30AM -0700, Marc Binderberger wrote: > sigh, this kind of re-using a protocol always has risks and personally > I still think we should introduce v2 BFD with 32 or 64 more bits in an > otherwise unchanged header and stop spending time on these "clever > protocol tricks". But then we won't proceed with S-BFD anymore and have > long discussions about the new BFD v2 packet (risk of another "IPv6" > with an uber-engineered protocol). So I understand nobody is keen on > the v2 topic :-) A "BFD v2" is not completely out of question but will have a fair amount of chair resistance to overcome to get us there. :-) In all cases, when we consider such new mechanisms, I shall always ask one critical question: Are your extensions to the protocol interesting enough that some very low-level hardware wants to hear about that new information once ever few milliseconds? If the answer is no, BFD may be the wrong place for it. So, the topic isn't off-limits, but build your case upon that premise. -- Jeff From nobody Mon Mar 17 12:01:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFBB1A049A for ; Mon, 17 Mar 2014 12:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRNBLD4MiODl for ; Mon, 17 Mar 2014 12:01:20 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA381A047A for ; Mon, 17 Mar 2014 12:01:17 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 1BB532AA0F; Mon, 17 Mar 2014 19:01:06 +0000 (GMT) Date: Mon, 17 Mar 2014 12:01:06 -0700 From: Marc Binderberger To: Girija Raghavendra Rao (giraghav) Message-ID: <20140317120106086794.0b34de58@sniff.de> In-Reply-To: References: Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dxb_yibTeuQRBbB5PrKdSGmn_JM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2014 19:01:25 -0000 Hello Girija playing with the state field is a bold move :-) Okay, it "violates" RFC5880 section "6.8.7. Transmitting BFD Control Packets" which says The contents of transmitted BFD Control packets MUST be set as follows: [...] State (Sta) Set to the value indicated by bfd.SessionState. but as the whole state machine has been changed I wonder if that's actually a real concern. My criticism about the state machine in "8.1.1. Initiator State machine" of the S-BFD draft is actually that it is a new state machine :-) Seriously: to maintain as much code/hw and spec (5880) as possible I would have kept the Down/Init/Up on the S-BFD originator side plus a rule for the reflector (1) MAY set the outgoing state to AdminDown (2) otherwise MUST copy the outgoing state from the incoming packet But this idea would definitely clash with your idea. Let's see what others think. Regards, Marc On Mon, 17 Mar 2014 10:33:48 +0000, Girija Raghavendra Rao (giraghav) wrote: > Hi Jeff, Marc, Nobo, BFDers, > > If using of "D" bit to differentiate initiator/Reflector generated packets > is not preferred, how about the second option listed in the start of this > thread? > > 2. Use of State field in the BFD control packets: > > Initiator will always send packets with State set to "DOWN" and > reflector will send back packets with state field set to "UP. > Reflectors will never reflect any packets with state as "UP". However > the only issue is the use of state field differently i.e. > state in the S-BFD control packet from initiator does not reflect > the local state which is anyway not significant at reflector. > > > > Thanks & Regards > R.Girija > > > > On 14/03/14 4:17 AM, "Sam Aldrin" wrote: > >> Comments inline. >> >> Sent from my iPad >> >>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" wrote: >>> >>> >>> Hi Jeff, Marc, BFDers, >>> >>> [Jeff wrote] >>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>> absence of >>>> a P-bit, F will still be set for security purposes upon reflection." >>> >>> This is certainly lesser evil than other evil ideas (especially v2 >>> BFD), I'll take it :) >>> S-BFD authors/collaborators & BFDers, comments? >>> (speak now or forever hold your peace) >> Catching on this long email thread, finally. >> >> I too prefer not going v2 way, as it creates more complexity or open up >> many more issues. >> P/F bits as suggested by Jeff is a good option and we should use it. Base >> document should document on how those bits should be used, that includes >> any interval change. >>> >>> [Jeff wrote] >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to >>>> inject an additional packet (perhaps a DoS on its own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling >>>> poll" >>>> scenario that had popped up much earlier in standardization. >>> >>> So bit it. >>> >>> [Marc wrote] >>>> ah well, we simply don't have enough flags in the BFD packet. You are >>>> sure >>>> we don't want a BFD "v2" to add another 32/64 bit for future flag use? >>>> ;-) >>> >>> I am very sure :) >>> >>> [Marc wrote] >>>> But seriously: as the S-BFD sender is effectively talking to itself >>>> you do not >>>> need P/F to synchronize two systems. The reflector can simply set the >>>> Required Min RX Interval as it wants and the S-BFD sender adjusts. >>> >>> True that's definitely a possibility, but someone will surely argue >>> that changing interval w/o presence of P bit will violate RFC5880. >> If it deviates from the way the P bit is presently being used, true. But >> if S-BFD could set rx interval differently to regular BFD as long as we >> document it right, we wouldn't be violating RFC5880, IMO. Do you think >> RFC is rigid about interval change? >>> >>> [Marc wrote] >>>> Also: as Jeff mentioned, without any "session state" on the reflector >>>> side it >>>> would be difficult to match any received F bit to a particular P sent >>>> out? >>> >>> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector now. >>> Reflector can still send [P=1, F=0], but that is >>> one-way-communication/request. >> >> Nod. >> >> Sam >>> >>> -Nobo >>> >>>> -----Original Message----- >>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>>> Sent: Thursday, March 13, 2014 4:28 PM >>>> To: Nobo Akiya (nobo) >>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>> >>>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>>>> I may be mis-remembering the conversation or mis-reading the >>>>>> document, but since the reflector is intended to be stateless why >>>>>> would it expect to receive a Final from the Initiator? >>>>> >>>>> It doesn't, reflector doesn't expect F bit (hence best effort). P bit >>>>> will alert >>>> initiator that parameter has changed (i.e. Required Min RX Interval has >>>> changed). >>>> >>>> Remember that the primary reason for the Required Min RX Interval in >>>> regular BFD is that the receiver is also running a timer and will use >>>> that for >>>> its state by helping to adjust the sender's speed in a graceful >>>> fashion. >>>> >>>> In this case, graceful is important since only the Initiator cares >>>> about the >>>> actual timing of the packets. >>>> >>>> And even then, for our original scenario: >>>> >>>> A---M---B >>>> >>>> As long as each side doesn't respond to F packets (but sends them), I >>>> think >>>> we're still good. I think this means you can keep the poll bit idea >>>> to help >>>> suggest an Initiator to slow down and still prevent DoS. In such a >>>> scenario, M >>>> is injecting packets to A, with or without P, using B's addressing. >>>> Without P, >>>> A could still respond with F and B would drop it. >>>> >>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>> absence of >>>> a P-bit, F will still be set for security purposes upon reflection." >>>> >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to >>>> inject an additional packet (perhaps a DoS on its own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling >>>> poll" >>>> scenario that had popped up much earlier in standardization. >>>> >>>> -- Jeff >>> >> > From nobody Mon Mar 17 18:36:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D556F1A033C for ; Mon, 17 Mar 2014 18:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGkUg-fEp8ey for ; Mon, 17 Mar 2014 18:36:13 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE61A0341 for ; Mon, 17 Mar 2014 18:36:12 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 816552AA0F; Tue, 18 Mar 2014 01:36:02 +0000 (GMT) Date: Mon, 17 Mar 2014 18:36:01 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140317183601756886.ce85139a@sniff.de> In-Reply-To: <20140317182952.GB13937@pfrc> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> Subject: BFD v2? (was: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/yYlUHEWrsHkdqjMjtskDHrv830Q Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 18 Mar 2014 01:36:16 -0000 Hello Jeff et al., slowly changing the subject. I don't want to create a roadblock for the S-BFD discussion. But S-BFD is a good example. Technically the redundant-session discussion we had a while ago was a good reason too to talk about "v2" but it probably would have been shot down as S-BFD should be able to cover this redundancy. The "do we need this" discussion for new drafts/RFCs will not and should not go away. In my opinion the only "flaw" BFD has is the lack of reserved fields to grow for new applications. Today we start bending the standard to fit something in. Even if we do a good job it's still likely to cause some trouble, simply because of BFDs success and the resulting number of implementations. Not to mention the time we - pardon - waste discussing which field(s) we can highjack. E.g. the main aspect, that a (R)eflected bit would be a neat solution for S-BFD to break a loop-attack - just takes a single bit, simple rules how to use it, simple to implement in hw/sw - is pushed into the background. We don't focus so much on what "doing the right thing" may be, we are just glad if it fits the existing RFC5880 in an acceptable manner. And still, to avoid the bigger "v2" topic delaying the discussions, we keep going. That's why I actually think it's time to do a next step and discuss "v2". My proposal would be fairly simple: just add a few 32bit fields. There is an upper limit, so NPs still can see the full IPv6+UDP+BFD packet (keep in mind some NPs process the first N bytes, the rest of the packet is DMAed "around" the NP, not through the NP) The proposal would look like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An optional Authentication Section MAY be present: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Authentication Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers: 2 The new packet would allow to include BFD v1 and it's standard. Effectively keep the new bytes zero and you have a BFD v1 "embedded" into BFD v2. RFCs would apply as they do today (modulo a larger packet length, obviously), so all the good things we have would remain. Fixed packet size. No TLV complexity, just flags and fixed fields. Small packets. And so on. And if you ask: why 64bit? Because it's a lot of flags, yet small enough to stop people from squeezing in an IPv6 address :-) Seriously, these details would need to be discussed. One relevant point is: don't think too complex, it's really just more room for flags or small fields. Because from my point of view that is the flaw to fix. > A "BFD v2" is not completely out of question but will have a fair amount of > chair resistance to overcome to get us there. :-) :-) Regards, Marc On Mon, 17 Mar 2014 14:29:52 -0400, Jeffrey Haas wrote: > On Mon, Mar 17, 2014 at 10:36:30AM -0700, Marc Binderberger wrote: >> sigh, this kind of re-using a protocol always has risks and personally >> I still think we should introduce v2 BFD with 32 or 64 more bits in an >> otherwise unchanged header and stop spending time on these "clever >> protocol tricks". But then we won't proceed with S-BFD anymore and have >> long discussions about the new BFD v2 packet (risk of another "IPv6" >> with an uber-engineered protocol). So I understand nobody is keen on >> the v2 topic :-) > > A "BFD v2" is not completely out of question but will have a fair amount of > chair resistance to overcome to get us there. :-) > > In all cases, when we consider such new mechanisms, I shall always ask one > critical question: Are your extensions to the protocol interesting enough > that some very low-level hardware wants to hear about that new information > once ever few milliseconds? If the answer is no, BFD may be the wrong place > for it. > > So, the topic isn't off-limits, but build your case upon that premise. > > -- Jeff > From nobody Tue Mar 18 07:47:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDEF1A044F for ; Tue, 18 Mar 2014 07:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKmPbRBQmP0C for ; Tue, 18 Mar 2014 07:47:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BE5D91A036E for ; Tue, 18 Mar 2014 07:47:23 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s2IElDtp016791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Mar 2014 09:47:13 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s2IEl8MT003183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 10:47:11 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 18 Mar 2014 10:47:09 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Tue, 18 Mar 2014 22:45:24 +0800 From: "Bhatia, Manav (Manav)" To: Marc Binderberger , Jeffrey Haas Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQkp1Ev75TJ+lmkSnSqpMvnrlXprm6GDA Date: Tue, 18 Mar 2014 14:45:22 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> In-Reply-To: <20140317183601756886.ce85139a@sniff.de> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6v8TQJqfNigjHcUIH85M84UuGGk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 18 Mar 2014 14:47:31 -0000 Hi Marc, If the "A" bit is set (authentication is present) then you can no longer em= bed the BFDv1 inside a BFDv2 packet since the parser for v1 assumes that th= e authentication info starts from a fixed offset from the start of the pack= et.=20 Any talk about a version upgrade before coming across real deployment issue= to solve is akin to putting a cart before the horse.=20 You have proposed a 64 bit reserved field assuming that this would fix all = the new and interesting stuff that we would want to do with BFD (in the fut= ure). Now assume, that we come across a use case that requires some additio= nal data to be carried along with the BFD packet. How will you do it? You will add a bit which when turned on would mean that the additional data= will be carried. But where will you store it - before the authentication d= ata or after it? If you place it before the auth data, then you would need = to carry some offset within the BFD packet that tells the receiver where th= e authentication data starts. This has not been accounted in your packet fo= rmat. If you do account for this, then we are unnecessarily complicating th= e packet. If you don't, then there is no guarantee that the new BFD packet format wil= l work for all possible extensions that we may expect from BFD. If you really want to be safe, then you need to go in for a TLV format -- s= ince that's always extensible. But, then you cant just go in for a TLV form= at when you expect the HW to consume the data (just makes life more complic= ated). I thus believe we should only go with a version upgrade if we really have n= o other option left and when we have a *real* issue that requires us to. Cheers, Manav > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Tuesday, March 18, 2014 7:06 AM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: BFD v2? (was: Loop Prevention in S-BFD (draft-akiya-bfd- > seamless-base)) >=20 > Hello Jeff et al., >=20 > slowly changing the subject. I don't want to create a roadblock for the > S-BFD discussion. >=20 > But S-BFD is a good example. Technically the redundant-session > discussion we had a while ago was a good reason too to talk about "v2" > but it probably would have been shot down as S-BFD should be able to > cover this redundancy. The "do we need this" discussion for new > drafts/RFCs will not and should not go away. >=20 > In my opinion the only "flaw" BFD has is the lack of reserved fields to > grow for new applications. Today we start bending the standard to fit > something in. Even if we do a good job it's still likely to cause some > trouble, simply because of BFDs success and the resulting number of > implementations. Not to mention the time we - pardon - waste discussing > which field(s) we can highjack. E.g. the main aspect, that a > (R)eflected bit would be a neat solution for S-BFD to break a > loop-attack - just takes a single bit, simple rules how to use it, > simple to implement in hw/sw - is pushed into the background. We don't > focus so much on what "doing the right thing" may be, we are just glad > if it fits the existing RFC5880 in an acceptable manner. >=20 > And still, to avoid the bigger "v2" topic delaying the discussions, we > keep going. That's why I actually think it's time to do a next step and > discuss "v2". >=20 >=20 > My proposal would be fairly simple: just add a few 32bit fields. There > is an upper limit, so NPs still can see the full IPv6+UDP+BFD packet > (keep in mind some NPs process the first N bytes, the rest of the > packet is DMAed "around" the NP, not through the NP) >=20 >=20 > The proposal would look like: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Your Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Desired Min TX Interval | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Required Min RX Interval | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Required Min Echo RX Interval | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved-1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved-2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > An optional Authentication Section MAY be present: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Auth Type | Auth Len | Authentication Data... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Vers: 2 >=20 >=20 > The new packet would allow to include BFD v1 and it's standard. > Effectively keep the new bytes zero and you have a BFD v1 "embedded" > into BFD v2. RFCs would apply as they do today (modulo a larger packet > length, obviously), so all the good things we have would remain. Fixed > packet size. No TLV complexity, just flags and fixed fields. Small > packets. And so on. >=20 > And if you ask: why 64bit? Because it's a lot of flags, yet small > enough to stop people from squeezing in an IPv6 address :-) Seriously, > these details would need to be discussed. One relevant point is: don't > think too complex, it's really just more room for flags or small > fields. Because from my point of view that is the flaw to fix. >=20 >=20 > > A "BFD v2" is not completely out of question but will have a fair > amount of > > chair resistance to overcome to get us there. :-) >=20 > :-) >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, 17 Mar 2014 14:29:52 -0400, Jeffrey Haas wrote: > > On Mon, Mar 17, 2014 at 10:36:30AM -0700, Marc Binderberger wrote: > >> sigh, this kind of re-using a protocol always has risks and > personally > >> I still think we should introduce v2 BFD with 32 or 64 more bits in > an > >> otherwise unchanged header and stop spending time on these "clever > >> protocol tricks". But then we won't proceed with S-BFD anymore and > have > >> long discussions about the new BFD v2 packet (risk of another "IPv6" > >> with an uber-engineered protocol). So I understand nobody is keen on > >> the v2 topic :-) > > > > A "BFD v2" is not completely out of question but will have a fair > amount of > > chair resistance to overcome to get us there. :-) > > > > In all cases, when we consider such new mechanisms, I shall always > ask one > > critical question: Are your extensions to the protocol interesting > enough > > that some very low-level hardware wants to hear about that new > information > > once ever few milliseconds? If the answer is no, BFD may be the wrong > place > > for it. > > > > So, the topic isn't off-limits, but build your case upon that > premise. > > > > -- Jeff > > From nobody Tue Mar 18 10:46:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A581A0296 for ; Tue, 18 Mar 2014 10:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OJ4CAQFpovL for ; Tue, 18 Mar 2014 10:46:34 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9911A0401 for ; Tue, 18 Mar 2014 10:46:34 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 214E32AA0F; Tue, 18 Mar 2014 17:46:22 +0000 (GMT) Date: Tue, 18 Mar 2014 10:46:25 -0700 From: Marc Binderberger To: "Bhatia, Manav (Manav)" Message-ID: <20140318104625080456.bebea936@sniff.de> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> Subject: RE: BFD v2? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5e8jXvp7rXGmkzNVHv_JM2fyldc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 18 Mar 2014 17:46:38 -0000 Hello Manav, okay, learned my first lesson and will avoid the word "embedding" as it creates the wrong expectations on your side :-) Obviously parsing a v2 packet is done with a v2 parser, not a v1 parser. But you can re-use large parts of the v1 parser, practically everything except the authentication, in the case that the v2 packet is "v1 packet plus zeros". That's what I named "embedded". Authentication would be done for the whole v2 packet. Sorry if this was causing confusion. > Any talk about a version upgrade before coming across real deployment > issue to solve is akin to putting a cart before the horse. I think I explained in my email why I think it's time for "v2", so your comment does not apply, IMO. Honestly, reading your reply there is not much constructive in it. I mentioned why I think what is the flaw. There is no answer to this in your email. The rest is "why this won't work". With this attitude no protocol would ever start flying. If you think 64bit is not enough - we can 96, 128. And "playing safe" with TLVs is exactly what I don't want. This is not ISIS or BGP. > I thus believe we should only go with a version upgrade if we really > have no other option left and when we have a *real* issue that > requires us to. sorry Manav, just read my email again. I explained what I propose to fix. Regards, Marc On Tue, 18 Mar 2014 14:45:22 +0000, Bhatia, Manav (Manav) wrote: > Hi Marc, > > If the "A" bit is set (authentication is present) then you can no > longer embed the BFDv1 inside a BFDv2 packet since the parser for v1 > assumes that the authentication info starts from a fixed offset from > the start of the packet. > > Any talk about a version upgrade before coming across real deployment > issue to solve is akin to putting a cart before the horse. > > You have proposed a 64 bit reserved field assuming that this would > fix all the new and interesting stuff that we would want to do with > BFD (in the future). Now assume, that we come across a use case that > requires some additional data to be carried along with the BFD > packet. How will you do it? > > You will add a bit which when turned on would mean that the > additional data will be carried. But where will you store it - before > the authentication data or after it? If you place it before the auth > data, then you would need to carry some offset within the BFD packet > that tells the receiver where the authentication data starts. This > has not been accounted in your packet format. If you do account for > this, then we are unnecessarily complicating the packet. > > If you don't, then there is no guarantee that the new BFD packet > format will work for all possible extensions that we may expect from > BFD. > > If you really want to be safe, then you need to go in for a TLV > format -- since that's always extensible. But, then you cant just go > in for a TLV format when you expect the HW to consume the data (just > makes life more complicated). > > I thus believe we should only go with a version upgrade if we really > have no other option left and when we have a *real* issue that > requires us to. > > Cheers, Manav > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> Binderberger >> Sent: Tuesday, March 18, 2014 7:06 AM >> To: Jeffrey Haas >> Cc: rtg-bfd@ietf.org >> Subject: BFD v2? (was: Loop Prevention in S-BFD (draft-akiya-bfd- >> seamless-base)) >> >> Hello Jeff et al., >> >> slowly changing the subject. I don't want to create a roadblock for the >> S-BFD discussion. >> >> But S-BFD is a good example. Technically the redundant-session >> discussion we had a while ago was a good reason too to talk about "v2" >> but it probably would have been shot down as S-BFD should be able to >> cover this redundancy. The "do we need this" discussion for new >> drafts/RFCs will not and should not go away. >> >> In my opinion the only "flaw" BFD has is the lack of reserved fields to >> grow for new applications. Today we start bending the standard to fit >> something in. Even if we do a good job it's still likely to cause some >> trouble, simply because of BFDs success and the resulting number of >> implementations. Not to mention the time we - pardon - waste discussing >> which field(s) we can highjack. E.g. the main aspect, that a >> (R)eflected bit would be a neat solution for S-BFD to break a >> loop-attack - just takes a single bit, simple rules how to use it, >> simple to implement in hw/sw - is pushed into the background. We don't >> focus so much on what "doing the right thing" may be, we are just glad >> if it fits the existing RFC5880 in an acceptable manner. >> >> And still, to avoid the bigger "v2" topic delaying the discussions, we >> keep going. That's why I actually think it's time to do a next step and >> discuss "v2". >> >> >> My proposal would be fairly simple: just add a few 32bit fields. There >> is an upper limit, so NPs still can see the full IPv6+UDP+BFD packet >> (keep in mind some NPs process the first N bytes, the rest of the >> packet is DMAed "around" the NP, not through the NP) >> >> >> The proposal would look like: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | My Discriminator | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Your Discriminator | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Desired Min TX Interval | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Required Min RX Interval | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Required Min Echo RX Interval | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved-1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved-2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> An optional Authentication Section MAY be present: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Auth Type | Auth Len | Authentication Data... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Vers: 2 >> >> >> The new packet would allow to include BFD v1 and it's standard. >> Effectively keep the new bytes zero and you have a BFD v1 "embedded" >> into BFD v2. RFCs would apply as they do today (modulo a larger packet >> length, obviously), so all the good things we have would remain. Fixed >> packet size. No TLV complexity, just flags and fixed fields. Small >> packets. And so on. >> >> And if you ask: why 64bit? Because it's a lot of flags, yet small >> enough to stop people from squeezing in an IPv6 address :-) Seriously, >> these details would need to be discussed. One relevant point is: don't >> think too complex, it's really just more room for flags or small >> fields. Because from my point of view that is the flaw to fix. >> >> >>> A "BFD v2" is not completely out of question but will have a fair >> amount of >>> chair resistance to overcome to get us there. :-) >> >> :-) >> >> Regards, Marc >> >> >> >> >> >> >> >> On Mon, 17 Mar 2014 14:29:52 -0400, Jeffrey Haas wrote: >>> On Mon, Mar 17, 2014 at 10:36:30AM -0700, Marc Binderberger wrote: >>>> sigh, this kind of re-using a protocol always has risks and >> personally >>>> I still think we should introduce v2 BFD with 32 or 64 more bits in >> an >>>> otherwise unchanged header and stop spending time on these "clever >>>> protocol tricks". But then we won't proceed with S-BFD anymore and >> have >>>> long discussions about the new BFD v2 packet (risk of another "IPv6" >>>> with an uber-engineered protocol). So I understand nobody is keen on >>>> the v2 topic :-) >>> >>> A "BFD v2" is not completely out of question but will have a fair >> amount of >>> chair resistance to overcome to get us there. :-) >>> >>> In all cases, when we consider such new mechanisms, I shall always >> ask one >>> critical question: Are your extensions to the protocol interesting >> enough >>> that some very low-level hardware wants to hear about that new >> information >>> once ever few milliseconds? If the answer is no, BFD may be the wrong >> place >>> for it. >>> >>> So, the topic isn't off-limits, but build your case upon that >> premise. >>> >>> -- Jeff >>> > From nobody Tue Mar 18 11:52:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A61A1A0452 for ; Tue, 18 Mar 2014 11:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIHByegHxbYo for ; Tue, 18 Mar 2014 11:52:46 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C06A1A0479 for ; Tue, 18 Mar 2014 11:52:45 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 681032AA0F; Tue, 18 Mar 2014 18:52:35 +0000 (GMT) Date: Tue, 18 Mar 2014 11:52:37 -0700 From: Marc Binderberger To: Vengada Prasad Govindan (venggovi) , MALLIK MUDIGONDA (mmudigon) , Nobo Akiya (nobo) Message-ID: <20140318115237318427.37d2294d@sniff.de> In-Reply-To: <20140317103630501812.259d0463@sniff.de> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/p7yGWgtlNjdk3COkBp3y9p2C_JM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 18 Mar 2014 18:52:48 -0000 Hello Mallik, Prasad et al., okay, the following looks a bit weird. Maybe it is :-) On the other hand it avoids dealing with the "flags" which seem to either hit formal or practical problems. The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.", both for the originator and the reflector. Unless there is an idea what "echo" would mean for S-BFD (which is already pretty close to an echo function itself), what about re-using this field (1) Initiator sets "Required Min Echo RX Interval" to zero (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value (3) the reflector is not reflecting a packet received with non-zero "Required Min Echo RX Interval" Basically the flag idea, just a different field. As echo functionality is driven on the initiator side - the remote side only informs if it allows and to what speed - I would not expect any adverse impact on the initiator side, even when the whole functionality (i.e. the code) is re-used for S-BFD on the initiator side. And RFC5880 doesn't put too many restrictions on echo and "Required Min Echo RX Interval". Feedback welcome :-) Btw, what happened to the discriminator discussion? If I recall right then the idea was the reflector is inserting a local discriminator into the my_discr field when sending out the reflected packet. Nobo mentioned this makes it impossible to differentiate reflectors - I admit he lost me at this point ;-) Was this discussion conclusive? No-Go for the discriminator idea? Regards, Marc On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: > Hello Mallik and Prasad, > >> 1. In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that we >> used against 'D' bit apply here too? > > what we discussed about the "D" bit was more on a formal level. For "D" > is would be a replacement of what it means in RFC5880 and this is > formally kind of a no-no. At least difficult to change. The P/F bit use > for S-BFD should, as far as I can see, work smoothly with the existing > RFC5880 interpretation. > > Receiving F-bit set while you are not in a Poll sequence anymore is > what existing implementations - which we want to re-use largely on the > S-BFD originator side - must support anyway. > > >> 2. Most of the H/W based implementations use P/F bits to punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. > > Thanks for your feedback on this aspect :-) I don't have any good > answer here. It would mean on the S-BFD originator side the hw needs a > differentiation based on the UDP port instead of simply re-using the > existing packet I/O. Or it needs at least a knob to suppress this F-bit > punting (which potentially breaks other things). > > >> 3. 'F' bit itself is now ambiguous. Implementations will have to go >> through extra logic to process a packet with 'F' bit set I.e to know >> if it is a reflected packet or a response to the poll that is >> initiated. > > Don't see that. The only difference it to drop F-bit packets when you > are about to reflect them - but the reflector is different code/hw > anyway. Otherwise as mentioned above you have already today the > situation of receiving F-bit packets while your are not in a Poll > sequence (anymore). > > > sigh, this kind of re-using a protocol always has risks and personally > I still think we should introduce v2 BFD with 32 or 64 more bits in an > otherwise unchanged header and stop spending time on these "clever > protocol tricks". But then we won't proceed with S-BFD anymore and have > long discussions about the new BFD v2 packet (risk of another "IPv6" > with an uber-engineered protocol). So I understand nobody is keen on > the v2 topic :-) > > > Really not any good answer from my side other than we may have to look > further for something else to "overload". > > > Regards, Marc > > > > On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) > wrote: >> Hello all, >> One comment inlined with GVP>. >> Thanks >> Prasad >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK >> MUDIGONDA (mmudigon) >> Sent: Monday, March 17, 2014 4:26 PM >> To: Sam Aldrin; Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hi All, >> >> From the discussions I understand that the following is the sequence >> being discussed: >> >> (Initiator)A=====M=====B(Reflector) >> >> Normal Sequence >> >> A to B: [p=0,F=0] ==> ping packets >> B to A: [p=0,F=1] ==> pong packets >> >> Timer negotiation (ack) >> >> A to B: [p=1,F=0] ==> ping packets >> B to A: [p=0,F=1] ==> pong packet with ack for timer poll >> >> Timer negotiation (nack) Dueling poll >> >> A to B: [p=1,F=0] ==> ping packets >> B to A: [p=0.F=1] ==> pong packet with ack for timer poll >> B to A: [p=1,F=0] ==> Reflector initiated poll >> >> We have a few questions: >> >> 1. In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that we >> used against 'D' bit apply here too? >> 2. Most of the H/W based implementations use P/F bits to punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. >> 3. 'F' bit itself is now ambiguous. Implementations will have to go >> through extra logic to process a packet with 'F' bit set I.e to know >> if it is a reflected packet or a response to the poll that is >> initiated. >> Thanks >> >> Regards >> Mallik >> From: Sam Aldrin >> Date: Friday 14 March 2014 4:17 AM >> To: "Nobo Akiya (nobo)" >> Cc: "rtg-bfd@ietf.org" >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Comments inline. >> >> Sent from my iPad >> >>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" wrote: >>> Hi Jeff, Marc, BFDers, >>> [Jeff wrote] >>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>> absence of >>>> a P-bit, F will still be set for security purposes upon reflection." >>> This is certainly lesser evil than other evil ideas (especially v2 >>> BFD), I'll take it :) >>> S-BFD authors/collaborators & BFDers, comments? >>> (speak now or forever hold your peace) >> Catching on this long email thread, finally. >> >> I too prefer not going v2 way, as it creates more complexity or open >> up many more issues. >> P/F bits as suggested by Jeff is a good option and we should use it. >> Base document should document on how those bits should be used, that >> includes any interval change. >>> [Jeff wrote] >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to >>>> inject an additional packet (perhaps a DoS on its own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling poll" >>>> scenario that had popped up much earlier in standardization. >>> So bit it. >>> [Marc wrote] >>>> ah well, we simply don't have enough flags in the BFD packet. You >>>> are sure >>>> we don't want a BFD "v2" to add another 32/64 bit for future flag >>>> use? ;-) >>> I am very sure :) >>> [Marc wrote] >>>> But seriously: as the S-BFD sender is effectively talking to itself >>>> you do not >>>> need P/F to synchronize two systems. The reflector can simply set the >>>> Required Min RX Interval as it wants and the S-BFD sender adjusts. >>> True that's definitely a possibility, but someone will surely argue >>> that changing interval w/o presence of P bit will violate RFC5880. >> If it deviates from the way the P bit is presently being used, true. >> But if S-BFD could set rx interval differently to regular BFD as long >> as we document it right, we wouldn't be violating RFC5880, IMO. Do >> you think RFC is rigid about interval change? >>> [Marc wrote] >>>> Also: as Jeff mentioned, without any "session state" on the >>>> reflector side it >>>> would be difficult to match any received F bit to a particular P >>>> sent out? >>> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector >>> now. Reflector can still send [P=1, F=0], but that is >>> one-way-communication/request. >> >> Nod. >> >> Sam >>> -Nobo >>>> -----Original Message----- >>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>>> Sent: Thursday, March 13, 2014 4:28 PM >>>> To: Nobo Akiya (nobo) >>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>>>> I may be mis-remembering the conversation or mis-reading the >>>>>> document, but since the reflector is intended to be stateless why >>>>>> would it expect to receive a Final from the Initiator? >>>>> It doesn't, reflector doesn't expect F bit (hence best effort). P >>>>> bit will alert >>>> initiator that parameter has changed (i.e. Required Min RX Interval has >>>> changed). >>>> Remember that the primary reason for the Required Min RX Interval in >>>> regular BFD is that the receiver is also running a timer and will >>>> use that for >>>> its state by helping to adjust the sender's speed in a graceful fashion. >>>> In this case, graceful is important since only the Initiator cares >>>> about the >>>> actual timing of the packets. >>>> And even then, for our original scenario: >>>> A---M---B >>>> As long as each side doesn't respond to F packets (but sends them), >>>> I think >>>> we're still good. I think this means you can keep the poll bit >>>> idea to help >>>> suggest an Initiator to slow down and still prevent DoS. In such a >>>> scenario, M >>>> is injecting packets to A, with or without P, using B's >>>> addressing. Without P, >>>> A could still respond with F and B would drop it. >>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>> absence of >>>> a P-bit, F will still be set for security purposes upon reflection." >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to >>>> inject an additional packet (perhaps a DoS on its own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling poll" >>>> scenario that had popped up much earlier in standardization. >>>> -- Jeff >>> >> >> > From nobody Tue Mar 18 12:03:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666461A048A for ; Tue, 18 Mar 2014 12:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.748 X-Spam-Level: X-Spam-Status: No, score=-12.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weC68lrjOCIn for ; Tue, 18 Mar 2014 12:03:37 -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 2CA761A0179 for ; Tue, 18 Mar 2014 12:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12520; q=dns/txt; s=iport; t=1395169410; x=1396379010; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QMnuVpEg0XHIKU2IY415j82lvcXdkhjfxPbrQRrNA8o=; b=ZCBNzWbHCs7leIq0z54hEXfIa8eXS+fM6MhuvYH4hBXqAvkQ4yXKYwfM nGRGlD2U2HcMrvC9sZvyM0qAIZm6T/bLsyrRwTSQ+y7aRl7iX38ajizCC r4Uf7O+zOmH27ET6nk4kzXpCpssJ08b1rmjeq77OzrIe8XMc8ThKJse1O c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALuXKFOtJXHB/2dsb2JhbABagmUhO1eqB5gcgS0WdIIlAQEBBDo/DAQCAQgRAwEBAQEKFAkHIREUCQgCBAENBQiHXQMRAQzJBA2HEheMSoE2CgcBHzEHBoMegRQEllmDH4s2hUiDLYFpCRci X-IronPort-AV: E=Sophos;i="4.97,679,1389744000"; d="scan'208";a="310964672" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 18 Mar 2014 19:03:30 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2IJ3S0C017656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 19:03:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 18 Mar 2014 14:03:27 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oA== Date: Tue, 18 Mar 2014 19:03:26 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140318115237318427.37d2294d@sniff.de> In-Reply-To: <20140318115237318427.37d2294d@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/N1ynytjZh2__fmuwymMPzIkW5Bc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 18 Mar 2014 19:03:40 -0000 Hi Marc, et al, Thanks for continued discussions on this topic. Just wanted to let you and others know that few of us have been studying ho= w BFD-Multipoint draft updated RX procedures of RFC5880, we should be able = to provide an update to this thread soon. BFD-Multipoint pointer: http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=3D1 -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, March 18, 2014 2:53 PM > To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA > (mmudigon); Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello Mallik, Prasad et al., >=20 > okay, the following looks a bit weird. Maybe it is :-) On the other hand = it > avoids dealing with the "flags" which seem to either hit formal or practi= cal > problems. >=20 > The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.= ", > both for the originator and the reflector. Unless there is an idea what "= echo" > would mean for S-BFD (which is already pretty close to an echo function > itself), what about re-using this field >=20 > (1) Initiator sets "Required Min Echo RX Interval" to zero > (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value > (3) the reflector is not reflecting a packet received with non-zero "Requ= ired > Min Echo RX Interval" >=20 >=20 > Basically the flag idea, just a different field. As echo functionality > is driven on the initiator side - the remote side only informs if it > allows and to what speed - I would not expect any adverse impact on the > initiator side, even when the whole functionality (i.e. the code) is > re-used for S-BFD on the initiator side. And RFC5880 doesn't put too > many restrictions on echo and "Required Min Echo RX Interval". >=20 >=20 > Feedback welcome :-) >=20 >=20 > Btw, what happened to the discriminator discussion? If I recall right > then the idea was the reflector is inserting a local discriminator into > the my_discr field when sending out the reflected packet. Nobo > mentioned this makes it impossible to differentiate reflectors - I > admit he lost me at this point ;-) Was this discussion conclusive? > No-Go for the discriminator idea? >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 > On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: > > Hello Mallik and Prasad, > > > >> 1. In the above P/F approach, we are still overloading the > >> interpretation of 'F' bit. In our view this is same as > >> re-interpreting/overloading 'D' bit. Don't the same arguments that we > >> used against 'D' bit apply here too? > > > > what we discussed about the "D" bit was more on a formal level. For "D" > > is would be a replacement of what it means in RFC5880 and this is > > formally kind of a no-no. At least difficult to change. The P/F bit use > > for S-BFD should, as far as I can see, work smoothly with the existing > > RFC5880 interpretation. > > > > Receiving F-bit set while you are not in a Poll sequence anymore is > > what existing implementations - which we want to re-use largely on the > > S-BFD originator side - must support anyway. > > > > > >> 2. Most of the H/W based implementations use P/F bits to > punt the > >> received packets to S/W . Overloading P/F bits may impact H/W based > >> implementations depending on these bits. > >> GVP> Fully agree, I would prefer an option not re-interpreting or > >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > >> assumptions that are hard to change. > > > > Thanks for your feedback on this aspect :-) I don't have any good > > answer here. It would mean on the S-BFD originator side the hw needs a > > differentiation based on the UDP port instead of simply re-using the > > existing packet I/O. Or it needs at least a knob to suppress this F-bit > > punting (which potentially breaks other things). > > > > > >> 3. 'F' bit itself is now ambiguous. Implementations will have to > go > >> through extra logic to process a packet with 'F' bit set I.e to know > >> if it is a reflected packet or a response to the poll that is > >> initiated. > > > > Don't see that. The only difference it to drop F-bit packets when you > > are about to reflect them - but the reflector is different code/hw > > anyway. Otherwise as mentioned above you have already today the > > situation of receiving F-bit packets while your are not in a Poll > > sequence (anymore). > > > > > > sigh, this kind of re-using a protocol always has risks and personally > > I still think we should introduce v2 BFD with 32 or 64 more bits in an > > otherwise unchanged header and stop spending time on these "clever > > protocol tricks". But then we won't proceed with S-BFD anymore and have > > long discussions about the new BFD v2 packet (risk of another "IPv6" > > with an uber-engineered protocol). So I understand nobody is keen on > > the v2 topic :-) > > > > > > Really not any good answer from my side other than we may have to look > > further for something else to "overload". > > > > > > Regards, Marc > > > > > > > > On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) > > wrote: > >> Hello all, > >> One comment inlined with GVP>. > >> Thanks > >> Prasad > >> > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > >> MUDIGONDA (mmudigon) > >> Sent: Monday, March 17, 2014 4:26 PM > >> To: Sam Aldrin; Nobo Akiya (nobo) > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> Hi All, > >> > >> From the discussions I understand that the following is the sequence > >> being discussed: > >> > >> (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) > >> > >> Normal Sequence > >> > >> A to B: [p=3D0,F=3D0] =3D=3D> ping packets > >> B to A: [p=3D0,F=3D1] =3D=3D> pong packets > >> > >> Timer negotiation (ack) > >> > >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets > >> B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll > >> > >> Timer negotiation (nack) Dueling poll > >> > >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets > >> B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll > >> B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll > >> > >> We have a few questions: > >> > >> 1. In the above P/F approach, we are still overloading the > >> interpretation of 'F' bit. In our view this is same as > >> re-interpreting/overloading 'D' bit. Don't the same arguments that we > >> used against 'D' bit apply here too? > >> 2. Most of the H/W based implementations use P/F bits to > punt the > >> received packets to S/W . Overloading P/F bits may impact H/W based > >> implementations depending on these bits. > >> GVP> Fully agree, I would prefer an option not re-interpreting or > >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > >> assumptions that are hard to change. > >> 3. 'F' bit itself is now ambiguous. Implementations will have to > go > >> through extra logic to process a packet with 'F' bit set I.e to know > >> if it is a reflected packet or a response to the poll that is > >> initiated. > >> Thanks > >> > >> Regards > >> Mallik > >> From: Sam Aldrin > >> Date: Friday 14 March 2014 4:17 AM > >> To: "Nobo Akiya (nobo)" > >> Cc: "rtg-bfd@ietf.org" > >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> Comments inline. > >> > >> Sent from my iPad > >> > >>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: > >>> Hi Jeff, Marc, BFDers, > >>> [Jeff wrote] > >>>> So, I suppose the suggested addition to the S-BFD logic is "in the > >>>> absence of > >>>> a P-bit, F will still be set for security purposes upon reflection." > >>> This is certainly lesser evil than other evil ideas (especially v2 > >>> BFD), I'll take it :) > >>> S-BFD authors/collaborators & BFDers, comments? > >>> (speak now or forever hold your peace) > >> Catching on this long email thread, finally. > >> > >> I too prefer not going v2 way, as it creates more complexity or open > >> up many more issues. > >> P/F bits as suggested by Jeff is a good option and we should use it. > >> Base document should document on how those bits should be used, that > >> includes any interval change. > >>> [Jeff wrote] > >>>> If a reflector wants to tell an Initiator to slow down, it would > >>>> simply need to > >>>> inject an additional packet (perhaps a DoS on its own, so should be > >>>> rate-limited) with the P bit set. This is effectively the "dueling = poll" > >>>> scenario that had popped up much earlier in standardization. > >>> So bit it. > >>> [Marc wrote] > >>>> ah well, we simply don't have enough flags in the BFD packet. You > >>>> are sure > >>>> we don't want a BFD "v2" to add another 32/64 bit for future flag > >>>> use? ;-) > >>> I am very sure :) > >>> [Marc wrote] > >>>> But seriously: as the S-BFD sender is effectively talking to itself > >>>> you do not > >>>> need P/F to synchronize two systems. The reflector can simply set th= e > >>>> Required Min RX Interval as it wants and the S-BFD sender adjusts. > >>> True that's definitely a possibility, but someone will surely argue > >>> that changing interval w/o presence of P bit will violate RFC5880. > >> If it deviates from the way the P bit is presently being used, true. > >> But if S-BFD could set rx interval differently to regular BFD as long > >> as we document it right, we wouldn't be violating RFC5880, IMO. Do > >> you think RFC is rigid about interval change? > >>> [Marc wrote] > >>>> Also: as Jeff mentioned, without any "session state" on the > >>>> reflector side it > >>>> would be difficult to match any received F bit to a particular P > >>>> sent out? > >>> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflecto= r > >>> now. Reflector can still send [P=3D1, F=3D0], but that is > >>> one-way-communication/request. > >> > >> Nod. > >> > >> Sam > >>> -Nobo > >>>> -----Original Message----- > >>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] > >>>> Sent: Thursday, March 13, 2014 4:28 PM > >>>> To: Nobo Akiya (nobo) > >>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org > >>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base= ) > >>>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: > >>>>>> I may be mis-remembering the conversation or mis-reading the > >>>>>> document, but since the reflector is intended to be stateless why > >>>>>> would it expect to receive a Final from the Initiator? > >>>>> It doesn't, reflector doesn't expect F bit (hence best effort). P > >>>>> bit will alert > >>>> initiator that parameter has changed (i.e. Required Min RX Interval = has > >>>> changed). > >>>> Remember that the primary reason for the Required Min RX Interval in > >>>> regular BFD is that the receiver is also running a timer and will > >>>> use that for > >>>> its state by helping to adjust the sender's speed in a graceful fash= ion. > >>>> In this case, graceful is important since only the Initiator cares > >>>> about the > >>>> actual timing of the packets. > >>>> And even then, for our original scenario: > >>>> A---M---B > >>>> As long as each side doesn't respond to F packets (but sends them), > >>>> I think > >>>> we're still good. I think this means you can keep the poll bit > >>>> idea to help > >>>> suggest an Initiator to slow down and still prevent DoS. In such a > >>>> scenario, M > >>>> is injecting packets to A, with or without P, using B's > >>>> addressing. Without P, > >>>> A could still respond with F and B would drop it. > >>>> So, I suppose the suggested addition to the S-BFD logic is "in the > >>>> absence of > >>>> a P-bit, F will still be set for security purposes upon reflection." > >>>> If a reflector wants to tell an Initiator to slow down, it would > >>>> simply need to > >>>> inject an additional packet (perhaps a DoS on its own, so should be > >>>> rate-limited) with the P bit set. This is effectively the "dueling = poll" > >>>> scenario that had popped up much earlier in standardization. > >>>> -- Jeff > >>> > >> > >> > > From nobody Tue Mar 18 19:18:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCF91A0308 for ; Tue, 18 Mar 2014 19:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLk-fossxTDg for ; Tue, 18 Mar 2014 19:18:46 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 61CCE1A0347 for ; Tue, 18 Mar 2014 19:18:45 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-cc-5328f89b0280 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.30.12743.C98F8235; Wed, 19 Mar 2014 02:53:32 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Tue, 18 Mar 2014 22:03:25 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Marc Binderberger , "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFJzQCAAQylgIAAnxeAgALHvwCAAAMxgIAAA9AAgAATlACAAAK8gIAAAjYAgAAC5ICAAAXLgIAAITAAgAWCtACAAAXDgIAAagsAgAGnmYCAAAMGAIAALS1A Date: Wed, 19 Mar 2014 02:03:24 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7861FF@eusaamb103.ericsson.se> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140318115237318427.37d2294d@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXSPn+6cHxrBBm8+iFnMvvKf2eLIq2PM FrM74i0+/9nGaDHzwyZmB1aPKb83snosWfKTyaN1dTdLAHMUl01Kak5mWWqRvl0CV8a5nyuY Ct7nVSy4vZK9gbEvoouRk0NCwETi6LNPLBC2mMSFe+vZuhi5OIQEjjBKnN3RDuUsZ5Q4+ms3 E0gVm4CRxIuNPewgCRGBfYwSrx/uAWtnFtCUaDrxmR3EFhZwlXj/dC4jiC0i4CZx79F8VoiG S4wSP9+9BpvEIqAq0Tr9DzOIzSvgK3Fv1SmwZiGBfUwSbffBhnICxdt7LoHZjED3fT+1hgli mbjErSfzmSDuFpBYsuc8M4QtKvHy8T9WCFtRYl//dHaIeh2JBbs/sUHY2hLLFr6G2isocXLm E5YJjGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLYxAiMqGMSbLo7GPe8tDzEKM3BoiTO ++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRp7eZT7quTXPrCNYxWY92bd2WpfADMug +/OmHhO+ULD9i7rT3c62nMd90fWdvvf4VqQwNKjpFZzcxO+5tdCIKUL0cI2r0YvlS3KZFn5q rRRY8F/p8ebVDmfENoVlvAp44nPQ/mzx5wwFxZZV13U5ElV/PNj81FFSduZVXqUlokr3nE7r S3DFKLEUZyQaajEXFScCAKn9JE12AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SrCzn62PK5Frvp3JzYHFC-N4nOQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 02:18:49 -0000 Dear All, very interesting discussion and feel sorry to not being able to participate= fully. If understand correctly, there's practical scenario that emphasizes need to= differentiate S-BFD Request and S-BFD Reply. I'm somewhat hesitant, even i= f chairs might look at this proposal kindly, to re-use defined in Base BFD = flags. At the same time, though yet implicit, we need the mechanism to work= with non-IP encapsulation of BFD, i.e. VCCV/G-ACh. As defined, S-BFD Reque= st being sent to new well-known Destination UDP port. I think that S-BFD Re= ply may be sent to another well-known Destination UDP port. (We may even us= e it as Source UDP port in S-BFD Request). And for non-IP encapsulation S-B= FD Response will have its own G-ACh, while S-BFD Reply will have G-ACh of i= ts own. Please let me know if I've missed this approach already being discussed. Regards, Greg PS. I like BFD.v2 approach better but I think that adding flags would solve= our problems for limited time. I agree that TLV-based extensions offer mor= e powerful and flexible mechanism. -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Tuesday, March 18, 2014 12:03 PM To: Marc Binderberger; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA= (mmudigon) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Marc, et al, Thanks for continued discussions on this topic. Just wanted to let you and others know that few of us have been studying ho= w BFD-Multipoint draft updated RX procedures of RFC5880, we should be able = to provide an update to this thread soon. BFD-Multipoint pointer: http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=3D1 -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, March 18, 2014 2:53 PM > To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon);=20 > Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello Mallik, Prasad et al., >=20 > okay, the following looks a bit weird. Maybe it is :-) On the other=20 > hand it avoids dealing with the "flags" which seem to either hit=20 > formal or practical problems. >=20 > The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be=20 > zero.", both for the originator and the reflector. Unless there is an ide= a what "echo" > would mean for S-BFD (which is already pretty close to an echo=20 > function itself), what about re-using this field >=20 > (1) Initiator sets "Required Min Echo RX Interval" to zero > (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value > (3) the reflector is not reflecting a packet received with non-zero=20 > "Required Min Echo RX Interval" >=20 >=20 > Basically the flag idea, just a different field. As echo functionality=20 > is driven on the initiator side - the remote side only informs if it=20 > allows and to what speed - I would not expect any adverse impact on=20 > the initiator side, even when the whole functionality (i.e. the code)=20 > is re-used for S-BFD on the initiator side. And RFC5880 doesn't put=20 > too many restrictions on echo and "Required Min Echo RX Interval". >=20 >=20 > Feedback welcome :-) >=20 >=20 > Btw, what happened to the discriminator discussion? If I recall right=20 > then the idea was the reflector is inserting a local discriminator=20 > into the my_discr field when sending out the reflected packet. Nobo=20 > mentioned this makes it impossible to differentiate reflectors - I=20 > admit he lost me at this point ;-) Was this discussion conclusive? > No-Go for the discriminator idea? >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 > On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: > > Hello Mallik and Prasad, > > > >> 1. In the above P/F approach, we are still overloading the > >> interpretation of 'F' bit. In our view this is same as=20 > >> re-interpreting/overloading 'D' bit. Don't the same arguments that=20 > >> we used against 'D' bit apply here too? > > > > what we discussed about the "D" bit was more on a formal level. For "D" > > is would be a replacement of what it means in RFC5880 and this is=20 > > formally kind of a no-no. At least difficult to change. The P/F bit=20 > > use for S-BFD should, as far as I can see, work smoothly with the=20 > > existing > > RFC5880 interpretation. > > > > Receiving F-bit set while you are not in a Poll sequence anymore is=20 > > what existing implementations - which we want to re-use largely on=20 > > the S-BFD originator side - must support anyway. > > > > > >> 2. Most of the H/W based implementations use P/F bits to > punt the > >> received packets to S/W . Overloading P/F bits may impact H/W based=20 > >> implementations depending on these bits. > >> GVP> Fully agree, I would prefer an option not re-interpreting or > >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA=20 > >> assumptions that are hard to change. > > > > Thanks for your feedback on this aspect :-) I don't have any good > > answer here. It would mean on the S-BFD originator side the hw needs=20 > > a differentiation based on the UDP port instead of simply re-using=20 > > the existing packet I/O. Or it needs at least a knob to suppress=20 > > this F-bit punting (which potentially breaks other things). > > > > > >> 3. 'F' bit itself is now ambiguous. Implementations will have to > go > >> through extra logic to process a packet with 'F' bit set I.e to=20 > >> know if it is a reflected packet or a response to the poll that is=20 > >> initiated. > > > > Don't see that. The only difference it to drop F-bit packets when=20 > > you are about to reflect them - but the reflector is different=20 > > code/hw anyway. Otherwise as mentioned above you have already today=20 > > the situation of receiving F-bit packets while your are not in a=20 > > Poll sequence (anymore). > > > > > > sigh, this kind of re-using a protocol always has risks and=20 > > personally I still think we should introduce v2 BFD with 32 or 64=20 > > more bits in an otherwise unchanged header and stop spending time on=20 > > these "clever protocol tricks". But then we won't proceed with S-BFD=20 > > anymore and have long discussions about the new BFD v2 packet (risk of = another "IPv6" > > with an uber-engineered protocol). So I understand nobody is keen on=20 > > the v2 topic :-) > > > > > > Really not any good answer from my side other than we may have to=20 > > look further for something else to "overload". > > > > > > Regards, Marc > > > > > > > > On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan=20 > > (venggovi) > > wrote: > >> Hello all, > >> One comment inlined with GVP>. > >> Thanks > >> Prasad > >> > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK=20 > >> MUDIGONDA (mmudigon) > >> Sent: Monday, March 17, 2014 4:26 PM > >> To: Sam Aldrin; Nobo Akiya (nobo) > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: Loop Prevention in S-BFD=20 > >> (draft-akiya-bfd-seamless-base) > >> > >> Hi All, > >> > >> From the discussions I understand that the following is the=20 > >> sequence being discussed: > >> > >> (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) > >> > >> Normal Sequence > >> > >> A to B: [p=3D0,F=3D0] =3D=3D> ping packets > >> B to A: [p=3D0,F=3D1] =3D=3D> pong packets > >> > >> Timer negotiation (ack) > >> > >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets > >> B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll > >> > >> Timer negotiation (nack) Dueling poll > >> > >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets > >> B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B to= A:=20 > >> [p=3D1,F=3D0] =3D=3D> Reflector initiated poll > >> > >> We have a few questions: > >> > >> 1. In the above P/F approach, we are still overloading the > >> interpretation of 'F' bit. In our view this is same as=20 > >> re-interpreting/overloading 'D' bit. Don't the same arguments that=20 > >> we used against 'D' bit apply here too? > >> 2. Most of the H/W based implementations use P/F bits to > punt the > >> received packets to S/W . Overloading P/F bits may impact H/W based=20 > >> implementations depending on these bits. > >> GVP> Fully agree, I would prefer an option not re-interpreting or > >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA=20 > >> assumptions that are hard to change. > >> 3. 'F' bit itself is now ambiguous. Implementations will have to > go > >> through extra logic to process a packet with 'F' bit set I.e to=20 > >> know if it is a reflected packet or a response to the poll that is=20 > >> initiated. > >> Thanks > >> > >> Regards > >> Mallik > >> From: Sam Aldrin > >> Date: Friday 14 March 2014 4:17 AM > >> To: "Nobo Akiya (nobo)" > >> Cc: "rtg-bfd@ietf.org" > >> Subject: Re: Loop Prevention in S-BFD=20 > >> (draft-akiya-bfd-seamless-base) > >> > >> Comments inline. > >> > >> Sent from my iPad > >> > >>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: > >>> Hi Jeff, Marc, BFDers, > >>> [Jeff wrote] > >>>> So, I suppose the suggested addition to the S-BFD logic is "in=20 > >>>> the absence of a P-bit, F will still be set for security purposes=20 > >>>> upon reflection." > >>> This is certainly lesser evil than other evil ideas (especially=20 > >>> v2 BFD), I'll take it :) S-BFD authors/collaborators & BFDers,=20 > >>> comments? > >>> (speak now or forever hold your peace) > >> Catching on this long email thread, finally. > >> > >> I too prefer not going v2 way, as it creates more complexity or=20 > >> open up many more issues. > >> P/F bits as suggested by Jeff is a good option and we should use it. > >> Base document should document on how those bits should be used,=20 > >> that includes any interval change. > >>> [Jeff wrote] > >>>> If a reflector wants to tell an Initiator to slow down, it would=20 > >>>> simply need to inject an additional packet (perhaps a DoS on its=20 > >>>> own, so should be > >>>> rate-limited) with the P bit set. This is effectively the "dueling = poll" > >>>> scenario that had popped up much earlier in standardization. > >>> So bit it. > >>> [Marc wrote] > >>>> ah well, we simply don't have enough flags in the BFD packet. You=20 > >>>> are sure we don't want a BFD "v2" to add another 32/64 bit for=20 > >>>> future flag use? ;-) > >>> I am very sure :) > >>> [Marc wrote] > >>>> But seriously: as the S-BFD sender is effectively talking to=20 > >>>> itself you do not need P/F to synchronize two systems. The=20 > >>>> reflector can simply set the Required Min RX Interval as it wants=20 > >>>> and the S-BFD sender adjusts. > >>> True that's definitely a possibility, but someone will surely=20 > >>> argue that changing interval w/o presence of P bit will violate RFC58= 80. > >> If it deviates from the way the P bit is presently being used, true. > >> But if S-BFD could set rx interval differently to regular BFD as=20 > >> long as we document it right, we wouldn't be violating RFC5880,=20 > >> IMO. Do you think RFC is rigid about interval change? > >>> [Marc wrote] > >>>> Also: as Jeff mentioned, without any "session state" on the=20 > >>>> reflector side it would be difficult to match any received F bit=20 > >>>> to a particular P sent out? > >>> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflecto= r=20 > >>> now. Reflector can still send [P=3D1, F=3D0], but that is=20 > >>> one-way-communication/request. > >> > >> Nod. > >> > >> Sam > >>> -Nobo > >>>> -----Original Message----- > >>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] > >>>> Sent: Thursday, March 13, 2014 4:28 PM > >>>> To: Nobo Akiya (nobo) > >>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org > >>>> Subject: Re: Loop Prevention in S-BFD=20 > >>>> (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM += 0000, Nobo Akiya (nobo) wrote: > >>>>>> I may be mis-remembering the conversation or mis-reading the=20 > >>>>>> document, but since the reflector is intended to be stateless=20 > >>>>>> why would it expect to receive a Final from the Initiator? > >>>>> It doesn't, reflector doesn't expect F bit (hence best effort).=20 > >>>>> P bit will alert > >>>> initiator that parameter has changed (i.e. Required Min RX=20 > >>>> Interval has changed). > >>>> Remember that the primary reason for the Required Min RX Interval=20 > >>>> in regular BFD is that the receiver is also running a timer and=20 > >>>> will use that for its state by helping to adjust the sender's=20 > >>>> speed in a graceful fashion. > >>>> In this case, graceful is important since only the Initiator=20 > >>>> cares about the actual timing of the packets. > >>>> And even then, for our original scenario: > >>>> A---M---B > >>>> As long as each side doesn't respond to F packets (but sends=20 > >>>> them), I think we're still good. I think this means you can keep=20 > >>>> the poll bit idea to help suggest an Initiator to slow down and=20 > >>>> still prevent DoS. In such a scenario, M is injecting packets to=20 > >>>> A, with or without P, using B's addressing. Without P, A could=20 > >>>> still respond with F and B would drop it. > >>>> So, I suppose the suggested addition to the S-BFD logic is "in=20 > >>>> the absence of a P-bit, F will still be set for security purposes=20 > >>>> upon reflection." > >>>> If a reflector wants to tell an Initiator to slow down, it would=20 > >>>> simply need to inject an additional packet (perhaps a DoS on its=20 > >>>> own, so should be > >>>> rate-limited) with the P bit set. This is effectively the "dueling = poll" > >>>> scenario that had popped up much earlier in standardization. > >>>> -- Jeff > >>> > >> > >> > > From nobody Tue Mar 18 21:47:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449B11A0364 for ; Tue, 18 Mar 2014 21:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bR64vK2g07U for ; Tue, 18 Mar 2014 21:47:10 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88A1A04B1 for ; Tue, 18 Mar 2014 21:47:09 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s2J4kxEJ002233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Mar 2014 23:47:00 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s2J4kwtM028116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 00:46:59 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Mar 2014 00:46:59 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 19 Mar 2014 12:46:41 +0800 From: "Bhatia, Manav (Manav)" To: "'Marc Binderberger'" Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQkp1Ev75TJ+lmkSnSqpMvnrlXprm6GDA//+w5YCAARvJwA== Date: Wed, 19 Mar 2014 04:46:40 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> In-Reply-To: <20140318104625080456.bebea936@sniff.de> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/76xPJ9N_ovv8nHcnZhULYxg4cps Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 04:47:13 -0000 Hi Marc, All I am saying is that we should not bump the version # till we have a use= case where we cant work with the existing fields at all and the change req= uired is so radical that upping the version # is the only recourse left. The other point, that I was rather unsuccessfully, trying to make was that = without a use case in mind, defining a new BFD header will not work as you = will still end up with cases where the new header will not be sufficient. W= ill we then move to BFD v3? > mentioned why I think what is the flaw. There is no answer to this in > your email. The rest is "why this won't work". With this attitude no The flaw you mention is the lack of more bits to extend BFD. Quoting your e= arlier email "Even if we do a good job it's still likely to cause some trou= ble, simply because of BFDs success and the resulting number of implementat= ions." This argument stands on tenuous grounds if you cant exactly qualify the "tr= ouble" that overloading certain bits can cause. We cant just say that there= will be trouble and start looking at radical changes in a protocol. This o= bviously changes if you can think of the issues we can expect when we start= overloading certain fields -- in this specific case the "D" bit. Cheers, Manav > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, March 18, 2014 11:16 PM > To: Bhatia, Manav (Manav) > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hello Manav, >=20 > okay, learned my first lesson and will avoid the word "embedding" as it > creates the wrong expectations on your side :-) >=20 > Obviously parsing a v2 packet is done with a v2 parser, not a v1 > parser. But you can re-use large parts of the v1 parser, practically > everything except the authentication, in the case that the v2 packet is > "v1 packet plus zeros". That's what I named "embedded". >=20 > Authentication would be done for the whole v2 packet. Sorry if this was > causing confusion. >=20 > > Any talk about a version upgrade before coming across real deployment > > issue to solve is akin to putting a cart before the horse. >=20 > I think I explained in my email why I think it's time for "v2", so your > comment does not apply, IMO. >=20 >=20 > Honestly, reading your reply there is not much constructive in it. I > mentioned why I think what is the flaw. There is no answer to this in > your email. The rest is "why this won't work". With this attitude no > protocol would ever start flying. If you think 64bit is not enough - we > can 96, 128. And "playing safe" with TLVs is exactly what I don't want. > This is not ISIS or BGP. >=20 > > I thus believe we should only go with a version upgrade if we really > > have no other option left and when we have a *real* issue that > > requires us to. >=20 > sorry Manav, just read my email again. I explained what I propose to > fix. >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 > On Tue, 18 Mar 2014 14:45:22 +0000, Bhatia, Manav (Manav) wrote: > > Hi Marc, > > > > If the "A" bit is set (authentication is present) then you can no > > longer embed the BFDv1 inside a BFDv2 packet since the parser for v1 > > assumes that the authentication info starts from a fixed offset from > > the start of the packet. > > > > Any talk about a version upgrade before coming across real deployment > > issue to solve is akin to putting a cart before the horse. > > > > You have proposed a 64 bit reserved field assuming that this would > > fix all the new and interesting stuff that we would want to do with > > BFD (in the future). Now assume, that we come across a use case that > > requires some additional data to be carried along with the BFD > > packet. How will you do it? > > > > You will add a bit which when turned on would mean that the > > additional data will be carried. But where will you store it - before > > the authentication data or after it? If you place it before the auth > > data, then you would need to carry some offset within the BFD packet > > that tells the receiver where the authentication data starts. This > > has not been accounted in your packet format. If you do account for > > this, then we are unnecessarily complicating the packet. > > > > If you don't, then there is no guarantee that the new BFD packet > > format will work for all possible extensions that we may expect from > > BFD. > > > > If you really want to be safe, then you need to go in for a TLV > > format -- since that's always extensible. But, then you cant just go > > in for a TLV format when you expect the HW to consume the data (just > > makes life more complicated). > > > > I thus believe we should only go with a version upgrade if we really > > have no other option left and when we have a *real* issue that > > requires us to. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > >> Binderberger > >> Sent: Tuesday, March 18, 2014 7:06 AM > >> To: Jeffrey Haas > >> Cc: rtg-bfd@ietf.org > >> Subject: BFD v2? (was: Loop Prevention in S-BFD (draft-akiya-bfd- > >> seamless-base)) > >> > >> Hello Jeff et al., > >> > >> slowly changing the subject. I don't want to create a roadblock for > the > >> S-BFD discussion. > >> > >> But S-BFD is a good example. Technically the redundant-session > >> discussion we had a while ago was a good reason too to talk about > "v2" > >> but it probably would have been shot down as S-BFD should be able to > >> cover this redundancy. The "do we need this" discussion for new > >> drafts/RFCs will not and should not go away. > >> > >> In my opinion the only "flaw" BFD has is the lack of reserved fields > to > >> grow for new applications. Today we start bending the standard to > fit > >> something in. Even if we do a good job it's still likely to cause > some > >> trouble, simply because of BFDs success and the resulting number of > >> implementations. Not to mention the time we - pardon - waste > discussing > >> which field(s) we can highjack. E.g. the main aspect, that a > >> (R)eflected bit would be a neat solution for S-BFD to break a > >> loop-attack - just takes a single bit, simple rules how to use it, > >> simple to implement in hw/sw - is pushed into the background. We > don't > >> focus so much on what "doing the right thing" may be, we are just > glad > >> if it fits the existing RFC5880 in an acceptable manner. > >> > >> And still, to avoid the bigger "v2" topic delaying the discussions, > we > >> keep going. That's why I actually think it's time to do a next step > and > >> discuss "v2". > >> > >> > >> My proposal would be fairly simple: just add a few 32bit fields. > There > >> is an upper limit, so NPs still can see the full IPv6+UDP+BFD packet > >> (keep in mind some NPs process the first N bytes, the rest of the > >> packet is DMAed "around" the NP, not through the NP) > >> > >> > >> The proposal would look like: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | My Discriminator | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Your Discriminator | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Desired Min TX Interval | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Required Min RX Interval | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Required Min Echo RX Interval | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Reserved-1 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Reserved-2 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> An optional Authentication Section MAY be present: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Auth Type | Auth Len | Authentication Data... | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Vers: 2 > >> > >> > >> The new packet would allow to include BFD v1 and it's standard. > >> Effectively keep the new bytes zero and you have a BFD v1 "embedded" > >> into BFD v2. RFCs would apply as they do today (modulo a larger > packet > >> length, obviously), so all the good things we have would remain. > Fixed > >> packet size. No TLV complexity, just flags and fixed fields. Small > >> packets. And so on. > >> > >> And if you ask: why 64bit? Because it's a lot of flags, yet small > >> enough to stop people from squeezing in an IPv6 address :-) > Seriously, > >> these details would need to be discussed. One relevant point is: > don't > >> think too complex, it's really just more room for flags or small > >> fields. Because from my point of view that is the flaw to fix. > >> > >> > >>> A "BFD v2" is not completely out of question but will have a fair > >> amount of > >>> chair resistance to overcome to get us there. :-) > >> > >> :-) > >> > >> Regards, Marc > >> > >> > >> > >> > >> > >> > >> > >> On Mon, 17 Mar 2014 14:29:52 -0400, Jeffrey Haas wrote: > >>> On Mon, Mar 17, 2014 at 10:36:30AM -0700, Marc Binderberger wrote: > >>>> sigh, this kind of re-using a protocol always has risks and > >> personally > >>>> I still think we should introduce v2 BFD with 32 or 64 more bits > in > >> an > >>>> otherwise unchanged header and stop spending time on these "clever > >>>> protocol tricks". But then we won't proceed with S-BFD anymore and > >> have > >>>> long discussions about the new BFD v2 packet (risk of another > "IPv6" > >>>> with an uber-engineered protocol). So I understand nobody is keen > on > >>>> the v2 topic :-) > >>> > >>> A "BFD v2" is not completely out of question but will have a fair > >> amount of > >>> chair resistance to overcome to get us there. :-) > >>> > >>> In all cases, when we consider such new mechanisms, I shall always > >> ask one > >>> critical question: Are your extensions to the protocol interesting > >> enough > >>> that some very low-level hardware wants to hear about that new > >> information > >>> once ever few milliseconds? If the answer is no, BFD may be the > wrong > >> place > >>> for it. > >>> > >>> So, the topic isn't off-limits, but build your case upon that > >> premise. > >>> > >>> -- Jeff > >>> > > From nobody Wed Mar 19 02:11:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CB21A069A for ; Wed, 19 Mar 2014 02:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WwBLGxhDsak for ; Wed, 19 Mar 2014 02:11:20 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id B44571A0283 for ; Wed, 19 Mar 2014 02:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35040; q=dns/txt; s=iport; t=1395220271; x=1396429871; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=8MQxeTsaG6K9H+vqwjJVrAtcA93lz3rxSxsxj1xvMtw=; b=aSx3JtiKOTy0eawE/6HYrkJCev6xSAVXfwKGdKKbSgYhXzWORY1ADpwj GetMdPIzgBGvidqEvPL2USqEGXE5VRVBo2usAbZfKjXa/uP3GLeHjc1Iq 5cceQqhdDlQSSb0Voa1BXM/X05jNr3H/GqjIh8bjMT3I1LK6W1F7BG621 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAGxeKVOtJXHB/2dsb2JhbABagkJEO1eqOoFkjT6IeoEaFnSCJQEBAQMBGl8FBwYBCBEDAQEBASAHJgIRFAkIAgQBDQWHZQMJCA3Hfw2HEheMTYE2CgcBPxEHBoQyBI50h2aBbYEyizaFSIMtgWkJFyI X-IronPort-AV: E=Sophos; i="4.97,684,1389744000"; d="scan'208,217"; a="28598993" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 19 Mar 2014 09:11:10 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2J9BA8R025846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 09:11:10 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 04:11:10 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , Marc Binderberger , "Vengada Prasad Govindan (venggovi)" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViA Date: Wed, 19 Mar 2014 09:11:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF4F5BBE1CFDBmmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bTKmj-sqkf95jHypm5N2QO8E9FU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 09:11:26 -0000 --_000_CF4F5BBE1CFDBmmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Yes, as you said there are different ways of doing this. Since we have a pr= ecedent for the 'M' bit getting updated in the latest multi-point draft, we= thought we will take the same route for our 'D' bit usage which is also, l= ike your echo Rx interval filed, pretty simple to implement. Regarding the discriminator usage for solving this, we do not want to put a= ny specific restrictions on the way discriminators are used. That's the rea= son the thread stopped there. Can't think of any particular use case where = MyDisc is used to demux, but that's the reason not to impose this restrict= ion. Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Wednesday 19 March 2014 12:33 AM To: Marc Binderberger >, "Vengada Prasa= d Govindan (venggovi)" >, Cis= co Employee > Cc: "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Marc, et al, Thanks for continued discussions on this topic. Just wanted to let you and others know that few of us have been studying ho= w BFD-Multipoint draft updated RX procedures of RFC5880, we should be able = to provide an update to this thread soon. BFD-Multipoint pointer: http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=3D1 -Nobo -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Tuesday, March 18, 2014 2:53 PM To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello Mallik, Prasad et al., okay, the following looks a bit weird. Maybe it is :-) On the other hand it avoids dealing with the "flags" which seem to either hit formal or practica= l problems. The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.", both for the originator and the reflector. Unless there is an idea what "ec= ho" would mean for S-BFD (which is already pretty close to an echo function itself), what about re-using this field (1) Initiator sets "Required Min Echo RX Interval" to zero (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value (3) the reflector is not reflecting a packet received with non-zero "Requir= ed Min Echo RX Interval" Basically the flag idea, just a different field. As echo functionality is driven on the initiator side - the remote side only informs if it allows and to what speed - I would not expect any adverse impact on the initiator side, even when the whole functionality (i.e. the code) is re-used for S-BFD on the initiator side. And RFC5880 doesn't put too many restrictions on echo and "Required Min Echo RX Interval". Feedback welcome :-) Btw, what happened to the discriminator discussion? If I recall right then the idea was the reflector is inserting a local discriminator into the my_discr field when sending out the reflected packet. Nobo mentioned this makes it impossible to differentiate reflectors - I admit he lost me at this point ;-) Was this discussion conclusive? No-Go for the discriminator idea? Regards, Marc On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: > Hello Mallik and Prasad, > >> 1. In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that we >> used against 'D' bit apply here too? > > what we discussed about the "D" bit was more on a formal level. For "D" > is would be a replacement of what it means in RFC5880 and this is > formally kind of a no-no. At least difficult to change. The P/F bit use > for S-BFD should, as far as I can see, work smoothly with the existing > RFC5880 interpretation. > > Receiving F-bit set while you are not in a Poll sequence anymore is > what existing implementations - which we want to re-use largely on the > S-BFD originator side - must support anyway. > > >> 2. Most of the H/W based implementations use P/F bits to punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. > > Thanks for your feedback on this aspect :-) I don't have any good > answer here. It would mean on the S-BFD originator side the hw needs a > differentiation based on the UDP port instead of simply re-using the > existing packet I/O. Or it needs at least a knob to suppress this F-bit > punting (which potentially breaks other things). > > >> 3. 'F' bit itself is now ambiguous. Implementations will have to go >> through extra logic to process a packet with 'F' bit set I.e to know >> if it is a reflected packet or a response to the poll that is >> initiated. > > Don't see that. The only difference it to drop F-bit packets when you > are about to reflect them - but the reflector is different code/hw > anyway. Otherwise as mentioned above you have already today the > situation of receiving F-bit packets while your are not in a Poll > sequence (anymore). > > > sigh, this kind of re-using a protocol always has risks and personally > I still think we should introduce v2 BFD with 32 or 64 more bits in an > otherwise unchanged header and stop spending time on these "clever > protocol tricks". But then we won't proceed with S-BFD anymore and have > long discussions about the new BFD v2 packet (risk of another "IPv6" > with an uber-engineered protocol). So I understand nobody is keen on > the v2 topic :-) > > > Really not any good answer from my side other than we may have to look > further for something else to "overload". > > > Regards, Marc > > > > On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) > wrote: >> Hello all, >> One comment inlined with GVP>. >> Thanks >> Prasad >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK >> MUDIGONDA (mmudigon) >> Sent: Monday, March 17, 2014 4:26 PM >> To: Sam Aldrin; Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hi All, >> >> From the discussions I understand that the following is the sequence >> being discussed: >> >> (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) >> >> Normal Sequence >> >> A to B: [p=3D0,F=3D0] =3D=3D> ping packets >> B to A: [p=3D0,F=3D1] =3D=3D> pong packets >> >> Timer negotiation (ack) >> >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets >> B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll >> >> Timer negotiation (nack) Dueling poll >> >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets >> B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll >> B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll >> >> We have a few questions: >> >> 1. In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that we >> used against 'D' bit apply here too? >> 2. Most of the H/W based implementations use P/F bits to punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. >> 3. 'F' bit itself is now ambiguous. Implementations will have to go >> through extra logic to process a packet with 'F' bit set I.e to know >> if it is a reflected packet or a response to the poll that is >> initiated. >> Thanks >> >> Regards >> Mallik >> From: Sam Aldrin > >> Date: Friday 14 March 2014 4:17 AM >> To: "Nobo Akiya (nobo)" > >> Cc: "rtg-bfd@ietf.org" > >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Comments inline. >> >> Sent from my iPad >> >>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: >>> Hi Jeff, Marc, BFDers, >>> [Jeff wrote] >>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>> absence of >>>> a P-bit, F will still be set for security purposes upon reflection." >>> This is certainly lesser evil than other evil ideas (especially v2 >>> BFD), I'll take it :) >>> S-BFD authors/collaborators & BFDers, comments? >>> (speak now or forever hold your peace) >> Catching on this long email thread, finally. >> >> I too prefer not going v2 way, as it creates more complexity or open >> up many more issues. >> P/F bits as suggested by Jeff is a good option and we should use it. >> Base document should document on how those bits should be used, that >> includes any interval change. >>> [Jeff wrote] >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to >>>> inject an additional packet (perhaps a DoS on its own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling po= ll" >>>> scenario that had popped up much earlier in standardization. >>> So bit it. >>> [Marc wrote] >>>> ah well, we simply don't have enough flags in the BFD packet. You >>>> are sure >>>> we don't want a BFD "v2" to add another 32/64 bit for future flag >>>> use? ;-) >>> I am very sure :) >>> [Marc wrote] >>>> But seriously: as the S-BFD sender is effectively talking to itself >>>> you do not >>>> need P/F to synchronize two systems. The reflector can simply set the >>>> Required Min RX Interval as it wants and the S-BFD sender adjusts. >>> True that's definitely a possibility, but someone will surely argue >>> that changing interval w/o presence of P bit will violate RFC5880. >> If it deviates from the way the P bit is presently being used, true. >> But if S-BFD could set rx interval differently to regular BFD as long >> as we document it right, we wouldn't be violating RFC5880, IMO. Do >> you think RFC is rigid about interval change? >>> [Marc wrote] >>>> Also: as Jeff mentioned, without any "session state" on the >>>> reflector side it >>>> would be difficult to match any received F bit to a particular P >>>> sent out? >>> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector >>> now. Reflector can still send [P=3D1, F=3D0], but that is >>> one-way-communication/request. >> >> Nod. >> >> Sam >>> -Nobo >>>> -----Original Message----- >>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>>> Sent: Thursday, March 13, 2014 4:28 PM >>>> To: Nobo Akiya (nobo) >>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>>>> I may be mis-remembering the conversation or mis-reading the >>>>>> document, but since the reflector is intended to be stateless why >>>>>> would it expect to receive a Final from the Initiator? >>>>> It doesn't, reflector doesn't expect F bit (hence best effort). P >>>>> bit will alert >>>> initiator that parameter has changed (i.e. Required Min RX Interval ha= s >>>> changed). >>>> Remember that the primary reason for the Required Min RX Interval in >>>> regular BFD is that the receiver is also running a timer and will >>>> use that for >>>> its state by helping to adjust the sender's speed in a graceful fashio= n. >>>> In this case, graceful is important since only the Initiator cares >>>> about the >>>> actual timing of the packets. >>>> And even then, for our original scenario: >>>> A---M---B >>>> As long as each side doesn't respond to F packets (but sends them), >>>> I think >>>> we're still good. I think this means you can keep the poll bit >>>> idea to help >>>> suggest an Initiator to slow down and still prevent DoS. In such a >>>> scenario, M >>>> is injecting packets to A, with or without P, using B's >>>> addressing. Without P, >>>> A could still respond with F and B would drop it. >>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>> absence of >>>> a P-bit, F will still be set for security purposes upon reflection." >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to >>>> inject an additional packet (perhaps a DoS on its own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling po= ll" >>>> scenario that had popped up much earlier in standardization. >>>> -- Jeff >>> >> >> > --_000_CF4F5BBE1CFDBmmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Marc,

Yes, as you said there are different ways of doing this. Since we have= a precedent for the 'M' bit getting updated in the latest multi-point draf= t, we thought we will take the same route for our 'D' bit usage which is al= so, like your echo Rx interval filed, pretty simple to implement.

Regarding the discriminator usage for solving this, we do not want to = put any specific restrictions on the way discriminators are used. That's th= e reason the thread stopped there. Can't think of any particular use case w= here MyDisc is used to demux, but that's the reason not  to impose this restriction.

Thanks

Regards
Mallik  

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Wednesday 19 March 2014 12:33= AM
To: Marc Binderberger <marc@sniff.de>, "Vengada Prasad Govin= dan (venggovi)" <venggovi@cis= co.com>, Cisco Employee <mm= udigon@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Hi Marc, et al,

Thanks for continued discussions on this topic.

Just wanted to let you and others know that few of us have been studyi= ng how BFD-Multipoint draft updated RX procedures of RFC5880, we should be = able to provide an update to this thread soon.

BFD-Multipoint pointer:

-Nobo

-----Original Message-----
From: Marc Binderberger [mailto:marc@= sniff.de]
Sent: Tuesday, March 18, 2014 2:53 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA
(mmudigon); Nobo Akiya (nobo)
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
Hello Mallik, Prasad et al.,
okay, the following looks a bit weird. Maybe it is :-) On the other ha= nd it
avoids dealing with the "flags" which seem to either hit for= mal or practical
problems.
The draft for S-BFD says ""Required Min Echo RX Interval&quo= t; SHOULD be zero.",
both for the originator and the reflector. Unless there is an idea wha= t "echo"
would mean for S-BFD (which is already pretty close to an echo functio= n
itself), what about re-using this field
(1) Initiator sets "Required Min Echo RX Interval" to zero
(2) Reflector sets "Required Min Echo RX Interval" to a non-= zero value
(3) the reflector is not reflecting a packet received with non-zero &q= uot;Required
Min Echo RX Interval"
Basically the flag idea, just a different field. As echo functionality=
is driven on the initiator side - the remote side only informs if it
allows and to what speed - I would not expect any adverse impact on th= e
initiator side, even when the whole functionality (i.e. the code) is
re-used for S-BFD on the initiator side. And RFC5880 doesn't put too
many restrictions on echo and "Required Min Echo RX Interval"= ;.
Feedback welcome :-)
Btw, what happened to the discriminator discussion?  If I re= call right
then the idea was the reflector is inserting a local discriminator int= o
the my_discr field when sending out the reflected packet. Nobo
mentioned this makes it impossible to differentiate reflectors - I
admit he lost me at this point ;-) Was this discussion conclusive?
No-Go for the discriminator idea?
Regards, Marc
On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote:
> Hello Mallik and Prasad,
>
>> 1. In the above P/F approach, we are still overloading the
>> interpretation of 'F' bit. In our view this is same as
>> re-interpreting/overloading 'D' bit. Don't the same arguments= that we
>> used against 'D' bit apply here too?
>
> what we discussed about the "D" bit was more on a forma= l level. For "D"
> is would be a replacement of what it means in RFC5880 and this is=
> formally kind of a no-no. At least difficult to change. The P/F b= it use
> for S-BFD should, as far as I can see, work smoothly with the exi= sting
> RFC5880 interpretation.
>
> Receiving F-bit set while you are not in a Poll sequence anymore = is
> what existing implementations - which we want to re-use largely o= n the
> S-BFD originator side - must support anyway.
>
>
>> 2. Most of the H/W based implementations use P/F bits to
punt the
>> received packets to S/W . Overloading P/F bits may impact H/W= based
>> implementations depending on these bits.
>> GVP> Fully agree, I would prefer an option not re-interpre= ting or
>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA=
>> assumptions that are hard to change.
>
> Thanks for your feedback on this aspect :-)   I don't h= ave any good
> answer here. It would mean on the S-BFD originator side the hw ne= eds a
> differentiation based on the UDP port instead of simply re-using = the
> existing packet I/O. Or it needs at least a knob to suppress this= F-bit
> punting (which potentially breaks other things).
>
>
>> 3. 'F' bit itself is now ambiguous. Implementations will have to
go
>> through extra logic to process a packet with 'F' bit set I.e = to know
>> if it is a reflected packet or a response to the poll that is=
>> initiated.
>
> Don't see that. The only difference it to drop F-bit packets when= you
> are about to reflect them - but the reflector is different code/h= w
> anyway. Otherwise as mentioned above you have already today the
> situation of receiving F-bit packets while your are not in a Poll=
> sequence (anymore).
>
>
> sigh, this kind of re-using a protocol always has risks and perso= nally
> I still think we should introduce v2 BFD with 32 or 64 more bits = in an
> otherwise unchanged header and stop spending time on these "= clever
> protocol tricks". But then we won't proceed with S-BFD anymo= re and have
> long discussions about the new BFD v2 packet (risk of another &qu= ot;IPv6"
> with an uber-engineered protocol). So I understand nobody is keen= on
> the v2 topic :-)
>
>
> Really not any good answer from my side other than we may have to= look
> further for something else to "overload".
>
>
> Regards, Marc
>
>
>
> On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (= venggovi)
> wrote:
>> Hello all,
>>   One comment inlined with GVP>.
>> Thanks
>> Prasad
>>
>> From: Rtg-bfd [ma= ilto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK
>> MUDIGONDA (mmudigon)
>> Sent: Monday, March 17, 2014 4:26 PM
>> To: Sam Aldrin; Nobo Akiya (nobo)
>> Cc: rtg-bfd@ietf.org<= /div>
>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamle= ss-base)
>>
>> Hi All,
>>
>> From the discussions I understand that the following is the s= equence
>> being discussed:
>>
>> (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector)
>>
>> Normal Sequence
>>
>> A to B: [p=3D0,F=3D0] =3D=3D> ping packets
>> B to A: [p=3D0,F=3D1] =3D=3D> pong packets
>>
>> Timer negotiation (ack)
>>
>> A to B: [p=3D1,F=3D0] =3D=3D> ping packets
>> B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for tim= er poll
>>
>> Timer negotiation (nack) Dueling poll
>>
>> A to B: [p=3D1,F=3D0] =3D=3D> ping packets
>> B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for tim= er poll
>> B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll
>>
>> We have a few questions:
>>
>> 1. In the above P/F approach, we are still overloading the
>> interpretation of 'F' bit. In our view this is same as
>> re-interpreting/overloading 'D' bit. Don't the same arguments= that we
>> used against 'D' bit apply here too?
>> 2. Most of the H/W based implementations use P/F bits to
punt the
>> received packets to S/W . Overloading P/F bits may impact H/W= based
>> implementations depending on these bits.
>> GVP> Fully agree, I would prefer an option not re-interpre= ting or
>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA=
>> assumptions that are hard to change.
>> 3. 'F' bit itself is now ambiguous. Implementations will have to
go
>> through extra logic to process a packet with 'F' bit set I.e = to know
>> if it is a reflected packet or a response to the poll that is=
>> initiated.
>>  Thanks
>>
>> Regards
>> Mallik
>> From: Sam Aldrin <aldrin.ietf@gmail.com>
>> Date: Friday 14 March 2014 4:17 AM
>> To: "Nobo Akiya (nobo)" <nobo@cisco.com>
>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamle= ss-base)
>>
>> Comments inline.
>>
>> Sent from my iPad
>>
>>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)"= ; <nobo@cisco.com>
wrote:
>>> Hi Jeff, Marc, BFDers,
>>> [Jeff wrote]
>>>> So, I suppose the suggested addition to the S-BFD log= ic is "in the
>>>> absence of
>>>> a P-bit, F will still be set for security purposes up= on reflection."
>>> This  is certainly lesser evil than other evil = ideas (especially v2
>>> BFD), I'll take it :)
>>> S-BFD authors/collaborators & BFDers, comments?
>>> (speak now or forever hold your peace)
>> Catching on this long email thread, finally.
>>
>> I too prefer not going v2 way, as it creates more complexity = or open
>> up many more issues.
>> P/F bits as suggested by Jeff is a good option and we should = use it.
>> Base document should document on how those bits should be use= d, that
>> includes any interval change.
>>> [Jeff wrote]
>>>> If a reflector wants to tell an Initiator to slow dow= n, it would
>>>> simply need to
>>>> inject an additional packet (perhaps a DoS on its own= , so should be
>>>> rate-limited) with the P bit set.  This is = effectively the "dueling poll"
>>>> scenario that had popped up much earlier in standardi= zation.
>>> So bit it.
>>> [Marc wrote]
>>>> ah well, we simply don't have enough flags in the BFD= packet. You
>>>> are sure
>>>> we don't want a BFD "v2" to add another 32/= 64 bit for future flag
>>>> use? ;-)
>>> I am very sure :)
>>> [Marc wrote]
>>>> But seriously: as the S-BFD sender is effectively tal= king to itself
>>>> you do not
>>>> need P/F to synchronize two systems. The reflector ca= n simply set the
>>>> Required Min RX Interval as it wants and the S-BFD se= nder adjusts.
>>> True that's definitely a possibility, but someone will su= rely argue
>>> that changing interval w/o presence of P bit will violate= RFC5880.
>> If it deviates from the way the P bit is presently being used= , true.
>> But if S-BFD could set rx interval differently to regular BFD= as long
>> as we document it right, we wouldn't  be violating = RFC5880, IMO. Do
>> you think RFC is rigid about interval change?
>>> [Marc wrote]
>>>> Also: as Jeff mentioned, without any "session st= ate" on the
>>>> reflector side it
>>>> would be difficult to match any received F bit to a p= articular P
>>>> sent out?
>>> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped= by reflector
>>> now. Reflector can still send [P=3D1, F=3D0], but that is=
>>> one-way-communication/request.
>>
>> Nod.
>>
>> Sam
>>> -Nobo
>>>> -----Original Message-----
>>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
>>>> Sent: Thursday, March 13, 2014 4:28 PM
>>>> To: Nobo Akiya (nobo)
>>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org
>>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bf= d-seamless-base)
>>>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Ak= iya (nobo) wrote:
>>>>>> I may be mis-remembering the conversation or = mis-reading the
>>>>>> document, but since the reflector is intended= to be stateless why
>>>>>> would it expect to receive a Final from the I= nitiator?
>>>>> It doesn't, reflector doesn't expect F bit (hence= best effort). P
>>>>> bit will alert
>>>> initiator that parameter has changed (i.e. Required M= in RX Interval has
>>>> changed).
>>>> Remember that the primary reason for the Required Min= RX Interval in
>>>> regular BFD is that the receiver is also running a ti= mer and will
>>>> use that for
>>>> its state by helping to adjust the sender's speed in = a graceful fashion.
>>>> In this case, graceful is important since only the In= itiator cares
>>>> about the
>>>> actual timing of the packets.
>>>> And even then, for our original scenario:
>>>> A---M---B
>>>> As long as each side doesn't respond to F packets (bu= t sends them),
>>>> I think
>>>> we're still good.  I think this means you c= an keep the poll bit
>>>> idea to help
>>>> suggest an Initiator to slow down and still prevent D= oS.  In such a
>>>> scenario, M
>>>> is injecting packets to A, with or without P, using B= 's
>>>> addressing.  Without P,
>>>> A could still respond with F and B would drop it.
>>>> So, I suppose the suggested addition to the S-BFD log= ic is "in the
>>>> absence of
>>>> a P-bit, F will still be set for security purposes up= on reflection."
>>>> If a reflector wants to tell an Initiator to slow dow= n, it would
>>>> simply need to
>>>> inject an additional packet (perhaps a DoS on its own= , so should be
>>>> rate-limited) with the P bit set.  This is = effectively the "dueling poll"
>>>> scenario that had popped up much earlier in standardi= zation.
>>>> -- Jeff
>>>
>>
>>
>

 --_000_CF4F5BBE1CFDBmmudigonciscocom_-- From nobody Wed Mar 19 05:14:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220BA1A0745 for ; Wed, 19 Mar 2014 05:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.747 X-Spam-Level: X-Spam-Status: No, score=-12.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak1VzlfqBn2g for ; Wed, 19 Mar 2014 05:14:45 -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 109651A03F9 for ; Wed, 19 Mar 2014 05:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38088; q=dns/txt; s=iport; t=1395231276; x=1396440876; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=HOJvAK7RdaUIrEv5iWnxyvXEa+5bwPlZkwHpL7sOhXU=; b=HgXDLOuhFBYWWJ1wPf1Tmulv/bwROBzaVPbrWzrnpQv5dIYgICl4CGWV FUMu0i/+8WHTxv2RYHWPXSe7Rd0dchhOdIDNkGpRRMcaGiREa9t7LsV5Y 7YcT5nNg7eA1GRu0a7g9jKlzKvlhOhGJWJG9VDaFXLtIIIzw7xBrA7fJe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGACeJKVOtJV2c/2dsb2JhbABagkJEO1eqMYFkjT6IeoEaFnSCJQEBAQMBGl8FBwYBCBEDAQEBASABBiYCERQJCAIEAQ0Fh2UDCQgNyCANhxIXjE2BNgoHAT8RBwaEMgSOdIdmgW2BMos2hUiDLYFpCRci X-IronPort-AV: E=Sophos;i="4.97,685,1389744000"; d="scan'208,217";a="311343516" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2014 12:14:29 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2JCETut017350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 12:14:29 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 07:14:29 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Gregory Mirsky , "Nobo Akiya (nobo)" , Marc Binderberger , "Vengada Prasad Govindan (venggovi)" Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAAJaQAgAEG7AA= Date: Wed, 19 Mar 2014 12:14:28 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7861FF@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.134] Content-Type: multipart/alternative; boundary="_000_CF4F86891CFF5mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qqTsXhPXj3ecTIf2bZ4ipz9CvDk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 12:14:54 -0000 --_000_CF4F86891CFF5mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Definitely this is an option that would work. It requires allocation of two= well-known UDP ports and also two G-Ach for non-ip encapsulations. The cur= rent discussions are all focussed on resolving the issue with BFD header fi= elds so that it is independent of the encapsulations. We would like to hear comments from others on this. Thanks Regards Mallik From: Gregory Mirsky > Date: Wednesday 19 March 2014 7:33 AM To: "Nobo Akiya (nobo)" >, Marc Binde= rberger >, "Vengada Prasad Govindan (ve= nggovi)" >, Cisco Employee > Cc: "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Dear All, very interesting discussion and feel sorry to not being able to participate= fully. If understand correctly, there's practical scenario that emphasizes need to= differentiate S-BFD Request and S-BFD Reply. I'm somewhat hesitant, even i= f chairs might look at this proposal kindly, to re-use defined in Base BFD = flags. At the same time, though yet implicit, we need the mechanism to work= with non-IP encapsulation of BFD, i.e. VCCV/G-ACh. As defined, S-BFD Reque= st being sent to new well-known Destination UDP port. I think that S-BFD Re= ply may be sent to another well-known Destination UDP port. (We may even us= e it as Source UDP port in S-BFD Request). And for non-IP encapsulation S-B= FD Response will have its own G-ACh, while S-BFD Reply will have G-ACh of i= ts own. Please let me know if I've missed this approach already being discussed. Regards, Greg PS. I like BFD.v2 approach better but I think that adding flags would solve= our problems for limited time. I agree that TLV-based extensions offer mor= e powerful and flexible mechanism. -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Tuesday, March 18, 2014 12:03 PM To: Marc Binderberger; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA= (mmudigon) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Marc, et al, Thanks for continued discussions on this topic. Just wanted to let you and others know that few of us have been studying ho= w BFD-Multipoint draft updated RX procedures of RFC5880, we should be able = to provide an update to this thread soon. BFD-Multipoint pointer: http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=3D1 -Nobo -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Tuesday, March 18, 2014 2:53 PM To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello Mallik, Prasad et al., okay, the following looks a bit weird. Maybe it is :-) On the other hand it avoids dealing with the "flags" which seem to either hit formal or practical problems. The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.", both for the originator and the reflector. Unless there is an idea = what "echo" would mean for S-BFD (which is already pretty close to an echo function itself), what about re-using this field (1) Initiator sets "Required Min Echo RX Interval" to zero (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value (3) the reflector is not reflecting a packet received with non-zero "Required Min Echo RX Interval" Basically the flag idea, just a different field. As echo functionality is driven on the initiator side - the remote side only informs if it allows and to what speed - I would not expect any adverse impact on the initiator side, even when the whole functionality (i.e. the code) is re-used for S-BFD on the initiator side. And RFC5880 doesn't put too many restrictions on echo and "Required Min Echo RX Interval". Feedback welcome :-) Btw, what happened to the discriminator discussion? If I recall right then the idea was the reflector is inserting a local discriminator into the my_discr field when sending out the reflected packet. Nobo mentioned this makes it impossible to differentiate reflectors - I admit he lost me at this point ;-) Was this discussion conclusive? No-Go for the discriminator idea? Regards, Marc On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: > Hello Mallik and Prasad, > >> 1. In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that >> we used against 'D' bit apply here too? > > what we discussed about the "D" bit was more on a formal level. For "D" > is would be a replacement of what it means in RFC5880 and this is > formally kind of a no-no. At least difficult to change. The P/F bit > use for S-BFD should, as far as I can see, work smoothly with the > existing > RFC5880 interpretation. > > Receiving F-bit set while you are not in a Poll sequence anymore is > what existing implementations - which we want to re-use largely on > the S-BFD originator side - must support anyway. > > >> 2. Most of the H/W based implementations use P/F bits to punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. > > Thanks for your feedback on this aspect :-) I don't have any good > answer here. It would mean on the S-BFD originator side the hw needs > a differentiation based on the UDP port instead of simply re-using > the existing packet I/O. Or it needs at least a knob to suppress > this F-bit punting (which potentially breaks other things). > > >> 3. 'F' bit itself is now ambiguous. Implementations will have to go >> through extra logic to process a packet with 'F' bit set I.e to >> know if it is a reflected packet or a response to the poll that is >> initiated. > > Don't see that. The only difference it to drop F-bit packets when > you are about to reflect them - but the reflector is different > code/hw anyway. Otherwise as mentioned above you have already today > the situation of receiving F-bit packets while your are not in a > Poll sequence (anymore). > > > sigh, this kind of re-using a protocol always has risks and > personally I still think we should introduce v2 BFD with 32 or 64 > more bits in an otherwise unchanged header and stop spending time on > these "clever protocol tricks". But then we won't proceed with S-BFD > anymore and have long discussions about the new BFD v2 packet (risk of an= other "IPv6" > with an uber-engineered protocol). So I understand nobody is keen on > the v2 topic :-) > > > Really not any good answer from my side other than we may have to > look further for something else to "overload". > > > Regards, Marc > > > > On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan > (venggovi) > wrote: >> Hello all, >> One comment inlined with GVP>. >> Thanks >> Prasad >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK >> MUDIGONDA (mmudigon) >> Sent: Monday, March 17, 2014 4:26 PM >> To: Sam Aldrin; Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD >> (draft-akiya-bfd-seamless-base) >> >> Hi All, >> >> From the discussions I understand that the following is the >> sequence being discussed: >> >> (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) >> >> Normal Sequence >> >> A to B: [p=3D0,F=3D0] =3D=3D> ping packets >> B to A: [p=3D0,F=3D1] =3D=3D> pong packets >> >> Timer negotiation (ack) >> >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets >> B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll >> >> Timer negotiation (nack) Dueling poll >> >> A to B: [p=3D1,F=3D0] =3D=3D> ping packets >> B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B to A= : >> [p=3D1,F=3D0] =3D=3D> Reflector initiated poll >> >> We have a few questions: >> >> 1. In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that >> we used against 'D' bit apply here too? >> 2. Most of the H/W based implementations use P/F bits to punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. >> 3. 'F' bit itself is now ambiguous. Implementations will have to go >> through extra logic to process a packet with 'F' bit set I.e to >> know if it is a reflected packet or a response to the poll that is >> initiated. >> Thanks >> >> Regards >> Mallik >> From: Sam Aldrin > >> Date: Friday 14 March 2014 4:17 AM >> To: "Nobo Akiya (nobo)" > >> Cc: "rtg-bfd@ietf.org" > >> Subject: Re: Loop Prevention in S-BFD >> (draft-akiya-bfd-seamless-base) >> >> Comments inline. >> >> Sent from my iPad >> >>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: >>> Hi Jeff, Marc, BFDers, >>> [Jeff wrote] >>>> So, I suppose the suggested addition to the S-BFD logic is "in >>>> the absence of a P-bit, F will still be set for security purposes >>>> upon reflection." >>> This is certainly lesser evil than other evil ideas (especially >>> v2 BFD), I'll take it :) S-BFD authors/collaborators & BFDers, >>> comments? >>> (speak now or forever hold your peace) >> Catching on this long email thread, finally. >> >> I too prefer not going v2 way, as it creates more complexity or >> open up many more issues. >> P/F bits as suggested by Jeff is a good option and we should use it. >> Base document should document on how those bits should be used, >> that includes any interval change. >>> [Jeff wrote] >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to inject an additional packet (perhaps a DoS on its >>>> own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling po= ll" >>>> scenario that had popped up much earlier in standardization. >>> So bit it. >>> [Marc wrote] >>>> ah well, we simply don't have enough flags in the BFD packet. You >>>> are sure we don't want a BFD "v2" to add another 32/64 bit for >>>> future flag use? ;-) >>> I am very sure :) >>> [Marc wrote] >>>> But seriously: as the S-BFD sender is effectively talking to >>>> itself you do not need P/F to synchronize two systems. The >>>> reflector can simply set the Required Min RX Interval as it wants >>>> and the S-BFD sender adjusts. >>> True that's definitely a possibility, but someone will surely >>> argue that changing interval w/o presence of P bit will violate RFC5880= . >> If it deviates from the way the P bit is presently being used, true. >> But if S-BFD could set rx interval differently to regular BFD as >> long as we document it right, we wouldn't be violating RFC5880, >> IMO. Do you think RFC is rigid about interval change? >>> [Marc wrote] >>>> Also: as Jeff mentioned, without any "session state" on the >>>> reflector side it would be difficult to match any received F bit >>>> to a particular P sent out? >>> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector >>> now. Reflector can still send [P=3D1, F=3D0], but that is >>> one-way-communication/request. >> >> Nod. >> >> Sam >>> -Nobo >>>> -----Original Message----- >>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>>> Sent: Thursday, March 13, 2014 4:28 PM >>>> To: Nobo Akiya (nobo) >>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >>>> Subject: Re: Loop Prevention in S-BFD >>>> (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM +00= 00, Nobo Akiya (nobo) wrote: >>>>>> I may be mis-remembering the conversation or mis-reading the >>>>>> document, but since the reflector is intended to be stateless >>>>>> why would it expect to receive a Final from the Initiator? >>>>> It doesn't, reflector doesn't expect F bit (hence best effort). >>>>> P bit will alert >>>> initiator that parameter has changed (i.e. Required Min RX >>>> Interval has changed). >>>> Remember that the primary reason for the Required Min RX Interval >>>> in regular BFD is that the receiver is also running a timer and >>>> will use that for its state by helping to adjust the sender's >>>> speed in a graceful fashion. >>>> In this case, graceful is important since only the Initiator >>>> cares about the actual timing of the packets. >>>> And even then, for our original scenario: >>>> A---M---B >>>> As long as each side doesn't respond to F packets (but sends >>>> them), I think we're still good. I think this means you can keep >>>> the poll bit idea to help suggest an Initiator to slow down and >>>> still prevent DoS. In such a scenario, M is injecting packets to >>>> A, with or without P, using B's addressing. Without P, A could >>>> still respond with F and B would drop it. >>>> So, I suppose the suggested addition to the S-BFD logic is "in >>>> the absence of a P-bit, F will still be set for security purposes >>>> upon reflection." >>>> If a reflector wants to tell an Initiator to slow down, it would >>>> simply need to inject an additional packet (perhaps a DoS on its >>>> own, so should be >>>> rate-limited) with the P bit set. This is effectively the "dueling po= ll" >>>> scenario that had popped up much earlier in standardization. >>>> -- Jeff >>> >> >> > --_000_CF4F86891CFF5mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Greg,

Definitely this is an option that would work. It requires allocation o= f two well-known UDP ports and also two G-Ach for non-ip encapsulations. Th= e current discussions are all focussed on resolving the issue with BFD head= er fields so that it is independent of the encapsulations. 
We would like to hear comments from others on this.

Thanks

Regards
Mallik 

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Wednesday 19 March 2014 7:33 = AM
To: "Nobo Akiya (nobo)" &= lt;nobo@cisco.com>, Marc Binderber= ger <marc@sniff.de>, "Venga= da Prasad Govindan (venggovi)" <venggovi@cisco.com>, Cisco Employee <mmudigon@cisco.co= m>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Dear All,
very interesting discussion and feel sorry to not being able to partic= ipate fully.
If understand correctly, there's practical scenario that emphasizes ne= ed to differentiate S-BFD Request and S-BFD Reply. I'm somewhat hesitant, e= ven if chairs might look at this proposal kindly, to re-use defined in Base= BFD flags. At the same time, though yet implicit, we need the mechanism to work with non-IP encapsulation of B= FD, i.e. VCCV/G-ACh. As defined, S-BFD Request being sent to new well-known= Destination UDP port. I think that S-BFD Reply may be sent to another well= -known Destination UDP port. (We may even use it as Source UDP port in S-BFD Request). And for non-IP encap= sulation S-BFD Response will have its own G-ACh, while S-BFD Reply will hav= e G-ACh of its own.

Please let me know if I've missed this  approach already bei= ng discussed.

Regard= s,
Greg

PS. I like BFD.v2 approach better but I think that adding flags would = solve our problems for limited time. I agree that TLV-based extensions offe= r more powerful and flexible mechanism.

-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, March 18, 2014 12:03 PM
To: Marc Binderberger; Vengada Prasad Govindan (venggovi); MALLIK MUDI= GONDA (mmudigon)
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>

Hi Marc, et al,

Thanks for continued discussions on this topic.

Just wanted to let you and others know that few of us have been studyi= ng how BFD-Multipoint draft updated RX procedures of RFC5880, we should be = able to provide an update to this thread soon.

BFD-Multipoint pointer:

-Nobo

-----Original Message-----
From: Marc Binderberger [mailto:marc@= sniff.de]
Sent: Tuesday, March 18, 2014 2:53 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); <= /div>
Nobo Akiya (nobo)
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
Hello Mallik, Prasad et al.,
okay, the following looks a bit weird. Maybe it is :-) On the other
hand it avoids dealing with the "flags" which seem to either= hit
formal or practical problems.
The draft for S-BFD says ""Required Min Echo RX Interval&quo= t; SHOULD be
zero.", both for the originator and the reflector. Unless there i= s an idea what "echo"
would mean for S-BFD (which is already pretty close to an echo
function itself), what about re-using this field
(1) Initiator sets "Required Min Echo RX Interval" to zero
(2) Reflector sets "Required Min Echo RX Interval" to a non-= zero value
(3) the reflector is not reflecting a packet received with non-zero
"Required Min Echo RX Interval"
Basically the flag idea, just a different field. As echo functionality=
is driven on the initiator side - the remote side only informs if it <= /div>
allows and to what speed - I would not expect any adverse impact on
the initiator side, even when the whole functionality (i.e. the code) =
is re-used for S-BFD on the initiator side. And RFC5880 doesn't put
too many restrictions on echo and "Required Min Echo RX Interval&= quot;.
Feedback welcome :-)
Btw, what happened to the discriminator discussion?  If I re= call right
then the idea was the reflector is inserting a local discriminator
into the my_discr field when sending out the reflected packet. Nobo
mentioned this makes it impossible to differentiate reflectors - I
admit he lost me at this point ;-) Was this discussion conclusive?
No-Go for the discriminator idea?
Regards, Marc
On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote:
> Hello Mallik and Prasad,
>
>> 1. In the above P/F approach, we are still overloading the
>> interpretation of 'F' bit. In our view this is same as
>> re-interpreting/overloading 'D' bit. Don't the same arguments= that
>> we used against 'D' bit apply here too?
>
> what we discussed about the "D" bit was more on a forma= l level. For "D"
> is would be a replacement of what it means in RFC5880 and this is=
> formally kind of a no-no. At least difficult to change. The P/F b= it
> use for S-BFD should, as far as I can see, work smoothly with the=
> existing
> RFC5880 interpretation.
>
> Receiving F-bit set while you are not in a Poll sequence anymore = is
> what existing implementations - which we want to re-use largely o= n
> the S-BFD originator side - must support anyway.
>
>
>> 2. Most of the H/W based implementations use P/F bits to
punt the
>> received packets to S/W . Overloading P/F bits may impact H/W= based
>> implementations depending on these bits.
>> GVP> Fully agree, I would prefer an option not re-interpre= ting or
>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA=
>> assumptions that are hard to change.
>
> Thanks for your feedback on this aspect :-)   I don't h= ave any good
> answer here. It would mean on the S-BFD originator side the hw ne= eds
> a differentiation based on the UDP port instead of simply re-usin= g
> the existing packet I/O. Or it needs at least a knob to suppress =
> this F-bit punting (which potentially breaks other things).
>
>
>> 3. 'F' bit itself is now ambiguous. Implementations will have to
go
>> through extra logic to process a packet with 'F' bit set I.e = to
>> know if it is a reflected packet or a response to the poll th= at is
>> initiated.
>
> Don't see that. The only difference it to drop F-bit packets when=
> you are about to reflect them - but the reflector is different
> code/hw anyway. Otherwise as mentioned above you have already tod= ay
> the situation of receiving F-bit packets while your are not in a =
> Poll sequence (anymore).
>
>
> sigh, this kind of re-using a protocol always has risks and
> personally I still think we should introduce v2 BFD with 32 or 64=
> more bits in an otherwise unchanged header and stop spending time= on
> these "clever protocol tricks". But then we won't proce= ed with S-BFD
> anymore and have long discussions about the new BFD v2 packet (ri= sk of another "IPv6"
> with an uber-engineered protocol). So I understand nobody is keen= on
> the v2 topic :-)
>
>
> Really not any good answer from my side other than we may have to=
> look further for something else to "overload".
>
>
> Regards, Marc
>
>
>
> On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan <= /div>
> (venggovi)
> wrote:
>> Hello all,
>>   One comment inlined with GVP>.
>> Thanks
>> Prasad
>>
>> From: Rtg-bfd [ma= ilto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK
>> MUDIGONDA (mmudigon)
>> Sent: Monday, March 17, 2014 4:26 PM
>> To: Sam Aldrin; Nobo Akiya (nobo)
>> Cc: rtg-bfd@ietf.org<= /div>
>> Subject: Re: Loop Prevention in S-BFD
>> (draft-akiya-bfd-seamless-base)
>>
>> Hi All,
>>
>> From the discussions I understand that the following is the <= /div>
>> sequence being discussed:
>>
>> (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector)
>>
>> Normal Sequence
>>
>> A to B: [p=3D0,F=3D0] =3D=3D> ping packets
>> B to A: [p=3D0,F=3D1] =3D=3D> pong packets
>>
>> Timer negotiation (ack)
>>
>> A to B: [p=3D1,F=3D0] =3D=3D> ping packets
>> B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for tim= er poll
>>
>> Timer negotiation (nack) Dueling poll
>>
>> A to B: [p=3D1,F=3D0] =3D=3D> ping packets
>> B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for tim= er poll B to A:
>> [p=3D1,F=3D0] =3D=3D> Reflector initiated poll
>>
>> We have a few questions:
>>
>> 1. In the above P/F approach, we are still overloading the
>> interpretation of 'F' bit. In our view this is same as
>> re-interpreting/overloading 'D' bit. Don't the same arguments= that
>> we used against 'D' bit apply here too?
>> 2. Most of the H/W based implementations use P/F bits to
punt the
>> received packets to S/W . Overloading P/F bits may impact H/W= based
>> implementations depending on these bits.
>> GVP> Fully agree, I would prefer an option not re-interpre= ting or
>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA=
>> assumptions that are hard to change.
>> 3. 'F' bit itself is now ambiguous. Implementations will have to
go
>> through extra logic to process a packet with 'F' bit set I.e = to
>> know if it is a reflected packet or a response to the poll th= at is
>> initiated.
>>  Thanks
>>
>> Regards
>> Mallik
>> From: Sam Aldrin <aldrin.ietf@gmail.com>
>> Date: Friday 14 March 2014 4:17 AM
>> To: "Nobo Akiya (nobo)" <nobo@cisco.com>
>> Subject: Re: Loop Prevention in S-BFD
>> (draft-akiya-bfd-seamless-base)
>>
>> Comments inline.
>>
>> Sent from my iPad
>>
>>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)"= ; <nobo@cisco.com>
wrote:
>>> Hi Jeff, Marc, BFDers,
>>> [Jeff wrote]
>>>> So, I suppose the suggested addition to the S-BFD log= ic is "in
>>>> the absence of a P-bit, F will still be set for secur= ity purposes
>>>> upon reflection."
>>> This  is certainly lesser evil than other evil = ideas (especially
>>> v2 BFD), I'll take it :) S-BFD authors/collaborators &= ; BFDers,
>>> comments?
>>> (speak now or forever hold your peace)
>> Catching on this long email thread, finally.
>>
>> I too prefer not going v2 way, as it creates more complexity = or
>> open up many more issues.
>> P/F bits as suggested by Jeff is a good option and we should = use it.
>> Base document should document on how those bits should be use= d,
>> that includes any interval change.
>>> [Jeff wrote]
>>>> If a reflector wants to tell an Initiator to slow dow= n, it would
>>>> simply need to inject an additional packet (perhaps a= DoS on its
>>>> own, so should be
>>>> rate-limited) with the P bit set.  This is = effectively the "dueling poll"
>>>> scenario that had popped up much earlier in standardi= zation.
>>> So bit it.
>>> [Marc wrote]
>>>> ah well, we simply don't have enough flags in the BFD= packet. You
>>>> are sure we don't want a BFD "v2" to add an= other 32/64 bit for
>>>> future flag use? ;-)
>>> I am very sure :)
>>> [Marc wrote]
>>>> But seriously: as the S-BFD sender is effectively tal= king to
>>>> itself you do not need P/F to synchronize two systems= . The
>>>> reflector can simply set the Required Min RX Interval= as it wants
>>>> and the S-BFD sender adjusts.
>>> True that's definitely a possibility, but someone will su= rely
>>> argue that changing interval w/o presence of P bit will v= iolate RFC5880.
>> If it deviates from the way the P bit is presently being used= , true.
>> But if S-BFD could set rx interval differently to regular BFD= as
>> long as we document it right, we wouldn't  be viola= ting RFC5880,
>> IMO. Do you think RFC is rigid about interval change?
>>> [Marc wrote]
>>>> Also: as Jeff mentioned, without any "session st= ate" on the
>>>> reflector side it would be difficult to match any rec= eived F bit
>>>> to a particular P sent out?
>>> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped= by reflector
>>> now. Reflector can still send [P=3D1, F=3D0], but that is=
>>> one-way-communication/request.
>>
>> Nod.
>>
>> Sam
>>> -Nobo
>>>> -----Original Message-----
>>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
>>>> Sent: Thursday, March 13, 2014 4:28 PM
>>>> To: Nobo Akiya (nobo)
>>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org
>>>> Subject: Re: Loop Prevention in S-BFD
>>>> (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 = at 08:17:22PM +0000, Nobo Akiya (nobo) wrote:
>>>>>> I may be mis-remembering the conversation or = mis-reading the
>>>>>> document, but since the reflector is intended= to be stateless
>>>>>> why would it expect to receive a Final from t= he Initiator?
>>>>> It doesn't, reflector doesn't expect F bit (hence= best effort).
>>>>> P bit will alert
>>>> initiator that parameter has changed (i.e. Required M= in RX
>>>> Interval has changed).
>>>> Remember that the primary reason for the Required Min= RX Interval
>>>> in regular BFD is that the receiver is also running a= timer and
>>>> will use that for its state by helping to adjust the = sender's
>>>> speed in a graceful fashion.
>>>> In this case, graceful is important since only the In= itiator
>>>> cares about the actual timing of the packets.
>>>> And even then, for our original scenario:
>>>> A---M---B
>>>> As long as each side doesn't respond to F packets (bu= t sends
>>>> them), I think we're still good.  I think t= his means you can keep
>>>> the poll bit idea to help suggest an Initiator to slo= w down and
>>>> still prevent DoS.  In such a scenario, M i= s injecting packets to
>>>> A, with or without P, using B's addressing. &nbs= p;Without P, A could
>>>> still respond with F and B would drop it.
>>>> So, I suppose the suggested addition to the S-BFD log= ic is "in
>>>> the absence of a P-bit, F will still be set for secur= ity purposes
>>>> upon reflection."
>>>> If a reflector wants to tell an Initiator to slow dow= n, it would
>>>> simply need to inject an additional packet (perhaps a= DoS on its
>>>> own, so should be
>>>> rate-limited) with the P bit set.  This is = effectively the "dueling poll"
>>>> scenario that had popped up much earlier in standardi= zation.
>>>> -- Jeff
>>>
>>
>>
>


--_000_CF4F86891CFF5mmudigonciscocom_-- From nobody Wed Mar 19 08:25:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6B11A077B for ; Wed, 19 Mar 2014 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srRCKqtvTrTJ for ; Wed, 19 Mar 2014 08:25:07 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A11A077F for ; Wed, 19 Mar 2014 08:25:06 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 645C92AA0F; Wed, 19 Mar 2014 15:24:55 +0000 (GMT) Date: Wed, 19 Mar 2014 08:25:01 -0700 From: Marc Binderberger To: MALLIK MUDIGONDA (mmudigon) Message-ID: <20140319082501342601.778988ca@sniff.de> In-Reply-To: References: Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4wA7sH0itmx44bRfMsHbellWW9o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 15:25:10 -0000 Hello Mallik, we will see how the discussion goes although I personally do not think the M and D bit can be compared. Seems other people didn't see D a good fit (formally) either. Anyway, I'll have a look again at the "M" bit and the multipoint draft. > Regarding the discriminator usage for solving this, we do not want to > put any specific restrictions on the way discriminators are used. what restriction? > That's the reason the thread stopped there. Can't think of any > particular use case where MyDisc is used to demux, but that's the > reason not to impose this restriction. Huh?! There is some misunderstanding here, so let me repeat the discriminator idea: (1) S-BFD initiator R1 sends a BFD packet to reflector R2 (2) Reflector R2 copies the my_discr from incoming packet into your_discr for outgoing packet. (3) Reflector R2 copies one of his local discriminator values into my_discr of the outgoing packet. This local discriminator is not a "reflector discriminator" of R2. (4) The S-BFD initiator R1 is doing normal BFD operations by looking into the your_discr of the reflected packet to demux. Especially R1 is not using "my_discr" of the reflected packet to demux. The point is: when someone is injecting an "endless loop" packet by using the "reflector discriminator" of R1 as my_discr, the reflector discriminator of R2 as your_discr and sends the packet to R2 then the steps above result in a packet attacker -> R2 -> R1 -> R2 -> drop/punt So after maximum 2 reflections the loop is broken. Regards, Marc On Wed, 19 Mar 2014 09:11:09 +0000, MALLIK MUDIGONDA (mmudigon) wrote: > Hi Marc, > > Yes, as you said there are different ways of doing this. Since we > have a precedent for the 'M' bit getting updated in the latest > multi-point draft, we thought we will take the same route for our 'D' > bit usage which is also, like your echo Rx interval filed, pretty > simple to implement. > > Regarding the discriminator usage for solving this, we do not want to > put any specific restrictions on the way discriminators are used. > That's the reason the thread stopped there. Can't think of any > particular use case where MyDisc is used to demux, but that's the > reason not to impose this restriction. > > Thanks > > Regards > Mallik > > From: "Nobo Akiya (nobo)" > Date: Wednesday 19 March 2014 12:33 AM > To: Marc Binderberger , "Vengada Prasad Govindan > (venggovi)" , Cisco Employee > Cc: "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > Hi Marc, et al, > > Thanks for continued discussions on this topic. > > Just wanted to let you and others know that few of us have been > studying how BFD-Multipoint draft updated RX procedures of RFC5880, > we should be able to provide an update to this thread soon. > > BFD-Multipoint pointer: > http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=1 > > -Nobo > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Tuesday, March 18, 2014 2:53 PM >> To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA >> (mmudigon); Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hello Mallik, Prasad et al., >> >> okay, the following looks a bit weird. Maybe it is :-) On the other hand it >> avoids dealing with the "flags" which seem to either hit formal or >> practical >> problems. >> >> The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.", >> both for the originator and the reflector. Unless there is an idea >> what "echo" >> would mean for S-BFD (which is already pretty close to an echo function >> itself), what about re-using this field >> >> (1) Initiator sets "Required Min Echo RX Interval" to zero >> (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value >> (3) the reflector is not reflecting a packet received with non-zero >> "Required >> Min Echo RX Interval" >> >> >> Basically the flag idea, just a different field. As echo functionality >> is driven on the initiator side - the remote side only informs if it >> allows and to what speed - I would not expect any adverse impact on the >> initiator side, even when the whole functionality (i.e. the code) is >> re-used for S-BFD on the initiator side. And RFC5880 doesn't put too >> many restrictions on echo and "Required Min Echo RX Interval". >> >> >> Feedback welcome :-) >> >> >> Btw, what happened to the discriminator discussion? If I recall right >> then the idea was the reflector is inserting a local discriminator into >> the my_discr field when sending out the reflected packet. Nobo >> mentioned this makes it impossible to differentiate reflectors - I >> admit he lost me at this point ;-) Was this discussion conclusive? >> No-Go for the discriminator idea? >> >> >> Regards, Marc >> >> >> >> >> >> On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: >>> Hello Mallik and Prasad, >>> >>>> 1. >> In the above P/F approach, we are still overloading the >>>> interpretation of 'F' bit. In our view this is same as >>>> re-interpreting/overloading 'D' bit. Don't the same arguments that we >>>> used against 'D' bit apply here too? >>> >>> what we discussed about the "D" bit was more on a formal level. For "D" >>> is would be a replacement of what it means in RFC5880 and this is >>> formally kind of a no-no. At least difficult to change. The P/F bit use >>> for S-BFD should, as far as I can see, work smoothly with the existing >>> RFC5880 interpretation. >>> >>> Receiving F-bit set while you are not in a Poll sequence anymore is >>> what existing implementations - which we want to re-use largely on the >>> S-BFD originator side - must support anyway. >>> >>> >>>> 2. >> Most of the H/W based implementations use P/F bits to >> punt the >>>> received packets to S/W . Overloading P/F bits may impact H/W based >>>> implementations depending on these bits. >>>> GVP> Fully agree, I would prefer an option not re-interpreting or >>>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >>>> assumptions that are hard to change. >>> >>> Thanks for your feedback on this aspect :-) I don't have any good >>> answer here. It would mean on the S-BFD originator side the hw needs a >>> differentiation based on the UDP port instead of simply re-using the >>> existing packet I/O. Or it needs at least a knob to suppress this F-bit >>> punting (which potentially breaks other things). >>> >>> >>>> 3. >> 'F' bit itself is now ambiguous. Implementations will have to >> go >>>> through extra logic to process a packet with 'F' bit set I.e to know >>>> if it is a reflected packet or a response to the poll that is >>>> initiated. >>> >>> Don't see that. The only difference it to drop F-bit packets when you >>> are about to reflect them - but the reflector is different code/hw >>> anyway. Otherwise as mentioned above you have already today the >>> situation of receiving F-bit packets while your are not in a Poll >>> sequence (anymore). >>> >>> >>> sigh, this kind of re-using a protocol always has risks and personally >>> I still think we should introduce v2 BFD with 32 or 64 more bits in an >>> otherwise unchanged header and stop spending time on these "clever >>> protocol tricks". But then we won't proceed with S-BFD anymore and have >>> long discussions about the new BFD v2 packet (risk of another "IPv6" >>> with an uber-engineered protocol). So I understand nobody is keen on >>> the v2 topic :-) >>> >>> >>> Really not any good answer from my side other than we may have to look >>> further for something else to "overload". >>> >>> >>> Regards, Marc >>> >>> >>> >>> On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) >>> wrote: >>>> Hello all, >>>> One comment inlined with GVP>. >>>> Thanks >>>> Prasad >>>> >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK >>>> MUDIGONDA (mmudigon) >>>> Sent: Monday, March 17, 2014 4:26 PM >>>> To: Sam Aldrin; Nobo Akiya (nobo) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>> >>>> Hi All, >>>> >>>> From the discussions I understand that the following is the sequence >>>> being discussed: >>>> >>>> (Initiator)A=====M=====B(Reflector) >>>> >>>> Normal Sequence >>>> >>>> A to B: [p=0,F=0] ==> ping packets >>>> B to A: [p=0,F=1] ==> pong packets >>>> >>>> Timer negotiation (ack) >>>> >>>> A to B: [p=1,F=0] ==> ping packets >>>> B to A: [p=0,F=1] ==> pong packet with ack for timer poll >>>> >>>> Timer negotiation (nack) Dueling poll >>>> >>>> A to B: [p=1,F=0] ==> ping packets >>>> B to A: [p=0.F=1] ==> pong packet with ack for timer poll >>>> B to A: [p=1,F=0] ==> Reflector initiated poll >>>> >>>> We have a few questions: >>>> >>>> 1. >> In the above P/F approach, we are still overloading the >>>> interpretation of 'F' bit. In our view this is same as >>>> re-interpreting/overloading 'D' bit. Don't the same arguments that we >>>> used against 'D' bit apply here too? >>>> 2. >> Most of the H/W based implementations use P/F bits to >> punt the >>>> received packets to S/W . Overloading P/F bits may impact H/W based >>>> implementations depending on these bits. >>>> GVP> Fully agree, I would prefer an option not re-interpreting or >>>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >>>> assumptions that are hard to change. >>>> 3. >> 'F' bit itself is now ambiguous. Implementations will have to >> go >>>> through extra logic to process a packet with 'F' bit set I.e to know >>>> if it is a reflected packet or a response to the poll that is >>>> initiated. >>>> Thanks >>>> >>>> Regards >>>> Mallik >>>> From: Sam Aldrin >>>> Date: Friday 14 March 2014 4:17 AM >>>> To: "Nobo Akiya (nobo)" >>>> Cc: "rtg-bfd@ietf.org" >>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>> >>>> Comments inline. >>>> >>>> Sent from my iPad >>>> >>>>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" >> wrote: >>>>> Hi Jeff, Marc, BFDers, >>>>> [Jeff wrote] >>>>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>>>> absence of >>>>>> a P-bit, F will still be set for security purposes upon reflection." >>>>> This is certainly lesser evil than other evil ideas (especially v2 >>>>> BFD), I'll take it :) >>>>> S-BFD authors/collaborators & BFDers, comments? >>>>> (speak now or forever hold your peace) >>>> Catching on this long email thread, finally. >>>> >>>> I too prefer not going v2 way, as it creates more complexity or open >>>> up many more issues. >>>> P/F bits as suggested by Jeff is a good option and we should use it. >>>> Base document should document on how those bits should be used, that >>>> includes any interval change. >>>>> [Jeff wrote] >>>>>> If a reflector wants to tell an Initiator to slow down, it would >>>>>> simply need to >>>>>> inject an additional packet (perhaps a DoS on its own, so should be >>>>>> rate-limited) with the P bit set. This is effectively the >> "dueling poll" >>>>>> scenario that had popped up much earlier in standardization. >>>>> So bit it. >>>>> [Marc wrote] >>>>>> ah well, we simply don't have enough flags in the BFD packet. You >>>>>> are sure >>>>>> we don't want a BFD "v2" to add another 32/64 bit for future flag >>>>>> use? ;-) >>>>> I am very sure :) >>>>> [Marc wrote] >>>>>> But seriously: as the S-BFD sender is effectively talking to itself >>>>>> you do not >>>>>> need P/F to synchronize two systems. The reflector can simply set the >>>>>> Required Min RX Interval as it wants and the S-BFD sender adjusts. >>>>> True that's definitely a possibility, but someone will surely argue >>>>> that changing interval w/o presence of P bit will violate RFC5880. >>>> If it deviates from the way the P bit is presently being used, true. >>>> But if S-BFD could set rx interval differently to regular BFD as long >>>> as we document it right, we wouldn't be violating RFC5880, IMO. Do >>>> you think RFC is rigid about interval change? >>>>> [Marc wrote] >>>>>> Also: as Jeff mentioned, without any "session state" on the >>>>>> reflector side it >>>>>> would be difficult to match any received F bit to a particular P >>>>>> sent out? >>>>> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector >>>>> now. Reflector can still send [P=1, F=0], but that is >>>>> one-way-communication/request. >>>> >>>> Nod. >>>> >>>> Sam >>>>> -Nobo >>>>>> -----Original Message----- >>>>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >>>>>> Sent: Thursday, March 13, 2014 4:28 PM >>>>>> To: Nobo Akiya (nobo) >>>>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >>>>>> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>>>> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >>>>>>>> I may be mis-remembering the conversation or mis-reading the >>>>>>>> document, but since the reflector is intended to be stateless why >>>>>>>> would it expect to receive a Final from the Initiator? >>>>>>> It doesn't, reflector doesn't expect F bit (hence best effort). P >>>>>>> bit will alert >>>>>> initiator that parameter has changed (i.e. Required Min RX >> Interval has >>>>>> changed). >>>>>> Remember that the primary reason for the Required Min RX Interval in >>>>>> regular BFD is that the receiver is also running a timer and will >>>>>> use that for >>>>>> its state by helping to adjust the sender's speed in a graceful >> fashion. >>>>>> In this case, graceful is important since only the Initiator cares >>>>>> about the >>>>>> actual timing of the packets. >>>>>> And even then, for our original scenario: >>>>>> A---M---B >>>>>> As long as each side doesn't respond to F packets (but sends them), >>>>>> I think >>>>>> we're still good. I think this means you can keep the poll bit >>>>>> idea to help >>>>>> suggest an Initiator to slow down and still prevent DoS. In such a >>>>>> scenario, M >>>>>> is injecting packets to A, with or without P, using B's >>>>>> addressing. Without P, >>>>>> A could still respond with F and B would drop it. >>>>>> So, I suppose the suggested addition to the S-BFD logic is "in the >>>>>> absence of >>>>>> a P-bit, F will still be set for security purposes upon reflection." >>>>>> If a reflector wants to tell an Initiator to slow down, it would >>>>>> simply need to >>>>>> inject an additional packet (perhaps a DoS on its own, so should be >>>>>> rate-limited) with the P bit set. This is effectively the >> "dueling poll" >>>>>> scenario that had popped up much earlier in standardization. >>>>>> -- Jeff >>>>> >>>> >>>> >>> > From nobody Wed Mar 19 08:52:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0F21A0774 for ; Wed, 19 Mar 2014 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.748 X-Spam-Level: X-Spam-Status: No, score=-7.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BraxR-2xRUV for ; Wed, 19 Mar 2014 08:52:29 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8D08F1A06B2 for ; Wed, 19 Mar 2014 08:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17448; q=dns/txt; s=iport; t=1395244340; x=1396453940; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WRBR2Ch6GKYkUqIMoCd4dcf+Pj7MQvM1tDRtvtQolzk=; b=Aj5GI/srYZE4NHhyohg1QhNAeUEXSlekvSUmuHmdG3Bh/Kn73Gj7ZVZo P682eF5yerzFzxANJqP0ahD0TEoWSTrFdAEuNXQsO/lYGocE+bo4H9S9D 0SMYxALgZR0tMdZDiW/HgjDBkm9s29hUCppENQKW1qduAF573yKD3Q5bc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFADy8KVOtJV2c/2dsb2JhbABagmUhO1eqMpgTgRkWdIIlAQEBAwEnEz8FBwQCAQgRAwEBAQEKFAkHIREUCQgCBAENBQiHXQMJCAEMyC4NhxIXjE2BNgoHAR8xBwaDHoEUBJZagx+LNoVIgy2BaQkXIg X-IronPort-AV: E=Sophos;i="4.97,686,1389744000"; d="scan'208";a="28697816" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 19 Mar 2014 15:52:19 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2JFqJ90002443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 15:52:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 10:52:18 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAE90UA== Date: Wed, 19 Mar 2014 15:52:17 +0000 Message-ID: References: <20140319082501342601.778988ca@sniff.de> In-Reply-To: <20140319082501342601.778988ca@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/mI1_4_nM9v2rum62hlXgYBG9oBQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 15:52:33 -0000 > we will see how the discussion goes although I personally do not think th= e > M and D bit can be compared. Seems other people didn't see D a good fit > (formally) either. Anyway, I'll have a look again at the "M" bit and the > multipoint draft. You are right Marc, M and D bit alone is not a good comparison. However, it= 's not just M bit that's updated in the multipoint draft. Multipoint draft = updates M bit, introduces new state variables (bfd.SessionType) and updates= RX procedures. Take a look at following sections in the multipoint draft. 4.4.1. New State Variable 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing BFD Control Packets Since your_discrim in S-BFD (both directions) is never zero(0), bfd.Session= Type is derivable for all cases. And D bit check can be added for new bfd.S= essionType values defined for S-BFD (both directions), as part of RX proced= ures. Not only this approach doesn't require BFDv2, it also addresses the p= oint raised by Greg (i.e. support for non-IP based S-BFD). -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Wednesday, March 19, 2014 11:25 AM > To: MALLIK MUDIGONDA (mmudigon) > Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello Mallik, >=20 > we will see how the discussion goes although I personally do not think th= e > M and D bit can be compared. Seems other people didn't see D a good fit > (formally) either. Anyway, I'll have a look again at the "M" bit and the > multipoint draft. >=20 >=20 > > Regarding the discriminator usage for solving this, we do not want to > > put any specific restrictions on the way discriminators are used. >=20 > what restriction? >=20 > > That's the reason the thread stopped there. Can't think of any > > particular use case where MyDisc is used to demux, but that's the > > reason not to impose this restriction. >=20 > Huh?! There is some misunderstanding here, so let me repeat the > discriminator idea: >=20 > (1) S-BFD initiator R1 sends a BFD packet to reflector R2 >=20 > (2) Reflector R2 copies the my_discr from incoming packet into your_discr > for outgoing packet. >=20 > (3) Reflector R2 copies one of his local discriminator values into my_dis= cr of > the outgoing packet. This local discriminator is not a "reflector > discriminator" of R2. >=20 > (4) The S-BFD initiator R1 is doing normal BFD operations by looking into= the > your_discr of the reflected packet to demux. >=20 > Especially R1 is not using "my_discr" of the reflected packet to demux. >=20 > The point is: when someone is injecting an "endless loop" packet by using > the "reflector discriminator" of R1 as my_discr, the reflector discrimina= tor of > R2 as your_discr and sends the packet to R2 then the steps above result i= n a > packet >=20 > attacker -> R2 -> R1 -> R2 -> drop/punt >=20 > So after maximum 2 reflections the loop is broken. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Wed, 19 Mar 2014 09:11:09 +0000, MALLIK MUDIGONDA (mmudigon) > wrote: > > Hi Marc, > > > > Yes, as you said there are different ways of doing this. Since we have > > a precedent for the 'M' bit getting updated in the latest multi-point > > draft, we thought we will take the same route for our 'D' > > bit usage which is also, like your echo Rx interval filed, pretty > > simple to implement. > > > > Regarding the discriminator usage for solving this, we do not want to > > put any specific restrictions on the way discriminators are used. > > That's the reason the thread stopped there. Can't think of any > > particular use case where MyDisc is used to demux, but that's the > > reason not to impose this restriction. > > > > Thanks > > > > Regards > > Mallik > > > > From: "Nobo Akiya (nobo)" > > Date: Wednesday 19 March 2014 12:33 AM > > To: Marc Binderberger , "Vengada Prasad Govindan > > (venggovi)" , Cisco Employee > > > Cc: "rtg-bfd@ietf.org" > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Hi Marc, et al, > > > > Thanks for continued discussions on this topic. > > > > Just wanted to let you and others know that few of us have been > > studying how BFD-Multipoint draft updated RX procedures of RFC5880, we > > should be able to provide an update to this thread soon. > > > > BFD-Multipoint pointer: > > http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_tex > > t=3D1 > > > > -Nobo > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Tuesday, March 18, 2014 2:53 PM > >> To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA > (mmudigon); > >> Nobo Akiya (nobo) > >> Cc: rtg-bfd@ietf.org > >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> Hello Mallik, Prasad et al., > >> > >> okay, the following looks a bit weird. Maybe it is :-) On the other > >> hand it avoids dealing with the "flags" which seem to either hit > >> formal or practical problems. > >> > >> The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be > >> zero.", both for the originator and the reflector. Unless there is an > >> idea what "echo" > >> would mean for S-BFD (which is already pretty close to an echo > >> function itself), what about re-using this field > >> > >> (1) Initiator sets "Required Min Echo RX Interval" to zero > >> (2) Reflector sets "Required Min Echo RX Interval" to a non-zero > >> value > >> (3) the reflector is not reflecting a packet received with non-zero > >> "Required Min Echo RX Interval" > >> > >> > >> Basically the flag idea, just a different field. As echo > >> functionality is driven on the initiator side - the remote side only > >> informs if it allows and to what speed - I would not expect any > >> adverse impact on the initiator side, even when the whole > >> functionality (i.e. the code) is re-used for S-BFD on the initiator > >> side. And RFC5880 doesn't put too many restrictions on echo and > "Required Min Echo RX Interval". > >> > >> > >> Feedback welcome :-) > >> > >> > >> Btw, what happened to the discriminator discussion? If I recall > >> right then the idea was the reflector is inserting a local > >> discriminator into the my_discr field when sending out the reflected > >> packet. Nobo mentioned this makes it impossible to differentiate > >> reflectors - I admit he lost me at this point ;-) Was this discussion > conclusive? > >> No-Go for the discriminator idea? > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> > >> On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: > >>> Hello Mallik and Prasad, > >>> > >>>> 1. > >> In the above P/F approach, we are still overloading the > >>>> interpretation of 'F' bit. In our view this is same as > >>>> re-interpreting/overloading 'D' bit. Don't the same arguments that > >>>> we used against 'D' bit apply here too? > >>> > >>> what we discussed about the "D" bit was more on a formal level. For "= D" > >>> is would be a replacement of what it means in RFC5880 and this is > >>> formally kind of a no-no. At least difficult to change. The P/F bit > >>> use for S-BFD should, as far as I can see, work smoothly with the > >>> existing > >>> RFC5880 interpretation. > >>> > >>> Receiving F-bit set while you are not in a Poll sequence anymore is > >>> what existing implementations - which we want to re-use largely on > >>> the S-BFD originator side - must support anyway. > >>> > >>> > >>>> 2. > >> Most of the H/W based implementations use P/F bits to punt the > >>>> received packets to S/W . Overloading P/F bits may impact H/W based > >>>> implementations depending on these bits. > >>>> GVP> Fully agree, I would prefer an option not re-interpreting or > >>>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > >>>> assumptions that are hard to change. > >>> > >>> Thanks for your feedback on this aspect :-) I don't have any good > >>> answer here. It would mean on the S-BFD originator side the hw needs > >>> a differentiation based on the UDP port instead of simply re-using > >>> the existing packet I/O. Or it needs at least a knob to suppress > >>> this F-bit punting (which potentially breaks other things). > >>> > >>> > >>>> 3. > >> 'F' bit itself is now ambiguous. Implementations will have to go > >>>> through extra logic to process a packet with 'F' bit set I.e to > >>>> know if it is a reflected packet or a response to the poll that is > >>>> initiated. > >>> > >>> Don't see that. The only difference it to drop F-bit packets when > >>> you are about to reflect them - but the reflector is different > >>> code/hw anyway. Otherwise as mentioned above you have already > today > >>> the situation of receiving F-bit packets while your are not in a > >>> Poll sequence (anymore). > >>> > >>> > >>> sigh, this kind of re-using a protocol always has risks and > >>> personally I still think we should introduce v2 BFD with 32 or 64 > >>> more bits in an otherwise unchanged header and stop spending time on > >>> these "clever protocol tricks". But then we won't proceed with S-BFD > >>> anymore and have long discussions about the new BFD v2 packet (risk o= f > another "IPv6" > >>> with an uber-engineered protocol). So I understand nobody is keen on > >>> the v2 topic :-) > >>> > >>> > >>> Really not any good answer from my side other than we may have to > >>> look further for something else to "overload". > >>> > >>> > >>> Regards, Marc > >>> > >>> > >>> > >>> On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan > >>> (venggovi) > >>> wrote: > >>>> Hello all, > >>>> One comment inlined with GVP>. > >>>> Thanks > >>>> Prasad > >>>> > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > >>>> MUDIGONDA (mmudigon) > >>>> Sent: Monday, March 17, 2014 4:26 PM > >>>> To: Sam Aldrin; Nobo Akiya (nobo) > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: Re: Loop Prevention in S-BFD > >>>> (draft-akiya-bfd-seamless-base) > >>>> > >>>> Hi All, > >>>> > >>>> From the discussions I understand that the following is the > >>>> sequence being discussed: > >>>> > >>>> (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) > >>>> > >>>> Normal Sequence > >>>> > >>>> A to B: [p=3D0,F=3D0] =3D=3D> ping packets > >>>> B to A: [p=3D0,F=3D1] =3D=3D> pong packets > >>>> > >>>> Timer negotiation (ack) > >>>> > >>>> A to B: [p=3D1,F=3D0] =3D=3D> ping packets > >>>> B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll > >>>> > >>>> Timer negotiation (nack) Dueling poll > >>>> > >>>> A to B: [p=3D1,F=3D0] =3D=3D> ping packets > >>>> B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B = to A: > >>>> [p=3D1,F=3D0] =3D=3D> Reflector initiated poll > >>>> > >>>> We have a few questions: > >>>> > >>>> 1. > >> In the above P/F approach, we are still overloading the > >>>> interpretation of 'F' bit. In our view this is same as > >>>> re-interpreting/overloading 'D' bit. Don't the same arguments that > >>>> we used against 'D' bit apply here too? > >>>> 2. > >> Most of the H/W based implementations use P/F bits to punt the > >>>> received packets to S/W . Overloading P/F bits may impact H/W based > >>>> implementations depending on these bits. > >>>> GVP> Fully agree, I would prefer an option not re-interpreting or > >>>> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > >>>> assumptions that are hard to change. > >>>> 3. > >> 'F' bit itself is now ambiguous. Implementations will have to go > >>>> through extra logic to process a packet with 'F' bit set I.e to > >>>> know if it is a reflected packet or a response to the poll that is > >>>> initiated. > >>>> Thanks > >>>> > >>>> Regards > >>>> Mallik > >>>> From: Sam Aldrin > >>>> Date: Friday 14 March 2014 4:17 AM > >>>> To: "Nobo Akiya (nobo)" > >>>> Cc: "rtg-bfd@ietf.org" > >>>> Subject: Re: Loop Prevention in S-BFD > >>>> (draft-akiya-bfd-seamless-base) > >>>> > >>>> Comments inline. > >>>> > >>>> Sent from my iPad > >>>> > >>>>> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > >> wrote: > >>>>> Hi Jeff, Marc, BFDers, > >>>>> [Jeff wrote] > >>>>>> So, I suppose the suggested addition to the S-BFD logic is "in > >>>>>> the absence of a P-bit, F will still be set for security purposes > >>>>>> upon reflection." > >>>>> This is certainly lesser evil than other evil ideas (especially > >>>>> v2 BFD), I'll take it :) S-BFD authors/collaborators & BFDers, > >>>>> comments? > >>>>> (speak now or forever hold your peace) > >>>> Catching on this long email thread, finally. > >>>> > >>>> I too prefer not going v2 way, as it creates more complexity or > >>>> open up many more issues. > >>>> P/F bits as suggested by Jeff is a good option and we should use it. > >>>> Base document should document on how those bits should be used, > >>>> that includes any interval change. > >>>>> [Jeff wrote] > >>>>>> If a reflector wants to tell an Initiator to slow down, it would > >>>>>> simply need to inject an additional packet (perhaps a DoS on its > >>>>>> own, so should be > >>>>>> rate-limited) with the P bit set. This is effectively the > >> "dueling poll" > >>>>>> scenario that had popped up much earlier in standardization. > >>>>> So bit it. > >>>>> [Marc wrote] > >>>>>> ah well, we simply don't have enough flags in the BFD packet. You > >>>>>> are sure we don't want a BFD "v2" to add another 32/64 bit for > >>>>>> future flag use? ;-) > >>>>> I am very sure :) > >>>>> [Marc wrote] > >>>>>> But seriously: as the S-BFD sender is effectively talking to > >>>>>> itself you do not need P/F to synchronize two systems. The > >>>>>> reflector can simply set the Required Min RX Interval as it wants > >>>>>> and the S-BFD sender adjusts. > >>>>> True that's definitely a possibility, but someone will surely > >>>>> argue that changing interval w/o presence of P bit will violate > RFC5880. > >>>> If it deviates from the way the P bit is presently being used, true. > >>>> But if S-BFD could set rx interval differently to regular BFD as > >>>> long as we document it right, we wouldn't be violating RFC5880, > >>>> IMO. Do you think RFC is rigid about interval change? > >>>>> [Marc wrote] > >>>>>> Also: as Jeff mentioned, without any "session state" on the > >>>>>> reflector side it would be difficult to match any received F bit > >>>>>> to a particular P sent out? > >>>>> With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflec= tor > >>>>> now. Reflector can still send [P=3D1, F=3D0], but that is > >>>>> one-way-communication/request. > >>>> > >>>> Nod. > >>>> > >>>> Sam > >>>>> -Nobo > >>>>>> -----Original Message----- > >>>>>> From: Jeffrey Haas [mailto:jhaas@pfrc.org] > >>>>>> Sent: Thursday, March 13, 2014 4:28 PM > >>>>>> To: Nobo Akiya (nobo) > >>>>>> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org > >>>>>> Subject: Re: Loop Prevention in S-BFD > >>>>>> (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM > +0000, Nobo Akiya (nobo) wrote: > >>>>>>>> I may be mis-remembering the conversation or mis-reading the > >>>>>>>> document, but since the reflector is intended to be stateless > >>>>>>>> why would it expect to receive a Final from the Initiator? > >>>>>>> It doesn't, reflector doesn't expect F bit (hence best effort). > >>>>>>> P bit will alert > >>>>>> initiator that parameter has changed (i.e. Required Min RX > >> Interval has > >>>>>> changed). > >>>>>> Remember that the primary reason for the Required Min RX Interval > >>>>>> in regular BFD is that the receiver is also running a timer and > >>>>>> will use that for its state by helping to adjust the sender's > >>>>>> speed in a graceful > >> fashion. > >>>>>> In this case, graceful is important since only the Initiator > >>>>>> cares about the actual timing of the packets. > >>>>>> And even then, for our original scenario: > >>>>>> A---M---B > >>>>>> As long as each side doesn't respond to F packets (but sends > >>>>>> them), I think we're still good. I think this means you can keep > >>>>>> the poll bit idea to help suggest an Initiator to slow down and > >>>>>> still prevent DoS. In such a scenario, M is injecting packets to > >>>>>> A, with or without P, using B's addressing. Without P, A could > >>>>>> still respond with F and B would drop it. > >>>>>> So, I suppose the suggested addition to the S-BFD logic is "in > >>>>>> the absence of a P-bit, F will still be set for security purposes > >>>>>> upon reflection." > >>>>>> If a reflector wants to tell an Initiator to slow down, it would > >>>>>> simply need to inject an additional packet (perhaps a DoS on its > >>>>>> own, so should be > >>>>>> rate-limited) with the P bit set. This is effectively the > >> "dueling poll" > >>>>>> scenario that had popped up much earlier in standardization. > >>>>>> -- Jeff > >>>>> > >>>> > >>>> > >>> > > From nobody Wed Mar 19 09:01:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68A01A040B for ; Wed, 19 Mar 2014 08:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqH9UlvDJdF4 for ; Wed, 19 Mar 2014 08:55:25 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 797F31A06B2 for ; Wed, 19 Mar 2014 08:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46864; q=dns/txt; s=iport; t=1395244516; x=1396454116; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=2faBk/Vu5gWT+E/DGEKGoFxuKEcwEA13a7NkfCHoMHY=; b=LL0j/K2wel9uc9xhl7oAucC5egdbsL8Z+U7la78qb+Q2sQfaoZ3Hm+7+ Jhc3pGAY6+tfgLbqdGfoCbbTO6Inn6Vd61wrDNSOpWc+To1IU8PRsJzO7 V3nM+VhkeBTZVo2Ku270ogrpwNBYEAfyiddYdWrrDGq95bvJZBbxMnD87 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAKW9KVOtJXG//2dsb2JhbABagkJEO1eqMoFkjT6IcYEZFnSCJQEBAQQaDVIMBgEIEQMBAQEhAQYmAhEUCQgCBA4Fh2UDEQ3ILg2HEheMTYE2CgcBPxEHBoQyBI50h2aBbYEyizaFSIMtgWkJFyI X-IronPort-AV: E=Sophos; i="4.97,686,1389744000"; d="scan'208,217"; a="28698068" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 19 Mar 2014 15:55:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2JFtAtU027414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 15:55:10 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 10:55:09 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Marc Binderberger Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAGSXAA== Date: Wed, 19 Mar 2014 15:55:09 +0000 Message-ID: In-Reply-To: <20140319082501342601.778988ca@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.30] Content-Type: multipart/alternative; boundary="_000_CF4FB9891D024mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ra4PPg_wD323p_4Lu4X0_ZG8tjY X-Mailman-Approved-At: Wed, 19 Mar 2014 09:01:38 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 15:55:29 -0000 --_000_CF4FB9891D024mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Yes, that was the original proposal. This was the original comment from Nob= o for the discriminator proposal: "Deviating discriminator by reflector session - Proposed will prevent a sin= gle S-BFD session to speak to multiple reflectors (cannot do reply demux'in= g), if implementation wants to do this or if there is ever such use-case." Even as per the original proposal, each reflector can have its own local di= scriminator value allocated. So in theory, every reflector can have a diffe= rent discriminator. Nobo, Any comments? Thanks Regards Mallik From: Marc Binderberger > Date: Wednesday 19 March 2014 8:55 PM To: Cisco Employee > Cc: "Nobo Akiya (nobo)" >, "Vengada P= rasad Govindan (venggovi)" >,= "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello Mallik, we will see how the discussion goes although I personally do not think the M and D bit can be compared. Seems other people didn't see D a good fit (formally) either. Anyway, I'll have a look again at the "M" bit and the multipoint draft. Regarding the discriminator usage for solving this, we do not want to put any specific restrictions on the way discriminators are used. what restriction? That's the reason the thread stopped there. Can't think of any particular use case where MyDisc is used to demux, but that's the reason not to impose this restriction. Huh?! There is some misunderstanding here, so let me repeat the discriminator idea: (1) S-BFD initiator R1 sends a BFD packet to reflector R2 (2) Reflector R2 copies the my_discr from incoming packet into your_discr for outgoing packet. (3) Reflector R2 copies one of his local discriminator values into my_discr of the outgoing packet. This local discriminator is not a "reflector discriminator" of R2. (4) The S-BFD initiator R1 is doing normal BFD operations by looking into the your_discr of the reflected packet to demux. Especially R1 is not using "my_discr" of the reflected packet to demux. The point is: when someone is injecting an "endless loop" packet by using the "reflector discriminator" of R1 as my_discr, the reflector discriminator of R2 as your_discr and sends the packet to R2 then the steps above result in a packet attacker -> R2 -> R1 -> R2 -> drop/punt So after maximum 2 reflections the loop is broken. Regards, Marc On Wed, 19 Mar 2014 09:11:09 +0000, MALLIK MUDIGONDA (mmudigon) wrote: Hi Marc, Yes, as you said there are different ways of doing this. Since we have a precedent for the 'M' bit getting updated in the latest multi-point draft, we thought we will take the same route for our 'D' bit usage which is also, like your echo Rx interval filed, pretty simple to implement. Regarding the discriminator usage for solving this, we do not want to put any specific restrictions on the way discriminators are used. That's the reason the thread stopped there. Can't think of any particular use case where MyDisc is used to demux, but that's the reason not to impose this restriction. Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Wednesday 19 March 2014 12:33 AM To: Marc Binderberger >, "Vengada Prasa= d Govindan (venggovi)" >, Cisco Employee= > Cc: "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi Marc, et al, Thanks for continued discussions on this topic. Just wanted to let you and others know that few of us have been studying how BFD-Multipoint draft updated RX procedures of RFC5880, we should be able to provide an update to this thread soon. BFD-Multipoint pointer: http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=3D1 -Nobo -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Tuesday, March 18, 2014 2:53 PM To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hello Mallik, Prasad et al., okay, the following looks a bit weird. Maybe it is :-) On the other hand it avoids dealing with the "flags" which seem to either hit formal or practical problems. The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.", both for the originator and the reflector. Unless there is an idea what "echo" would mean for S-BFD (which is already pretty close to an echo function itself), what about re-using this field (1) Initiator sets "Required Min Echo RX Interval" to zero (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value (3) the reflector is not reflecting a packet received with non-zero "Required Min Echo RX Interval" Basically the flag idea, just a different field. As echo functionality is driven on the initiator side - the remote side only informs if it allows and to what speed - I would not expect any adverse impact on the initiator side, even when the whole functionality (i.e. the code) is re-used for S-BFD on the initiator side. And RFC5880 doesn't put too many restrictions on echo and "Required Min Echo RX Interval". Feedback welcome :-) Btw, what happened to the discriminator discussion? If I recall right then the idea was the reflector is inserting a local discriminator into the my_discr field when sending out the reflected packet. Nobo mentioned this makes it impossible to differentiate reflectors - I admit he lost me at this point ;-) Was this discussion conclusive? No-Go for the discriminator idea? Regards, Marc On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: Hello Mallik and Prasad, 1. In the above P/F approach, we are still overloading the interpretation of 'F' bit. In our view this is same as re-interpreting/overloading 'D' bit. Don't the same arguments that we used against 'D' bit apply here too? what we discussed about the "D" bit was more on a formal level. For "D" is would be a replacement of what it means in RFC5880 and this is formally kind of a no-no. At least difficult to change. The P/F bit use for S-BFD should, as far as I can see, work smoothly with the existing RFC5880 interpretation. Receiving F-bit set while you are not in a Poll sequence anymore is what existing implementations - which we want to re-use largely on the S-BFD originator side - must support anyway. 2. Most of the H/W based implementations use P/F bits to punt the received packets to S/W . Overloading P/F bits may impact H/W based implementations depending on these bits. GVP> Fully agree, I would prefer an option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to change. Thanks for your feedback on this aspect :-) I don't have any good answer here. It would mean on the S-BFD originator side the hw needs a differentiation based on the UDP port instead of simply re-using the existing packet I/O. Or it needs at least a knob to suppress this F-bit punting (which potentially breaks other things). 3. 'F' bit itself is now ambiguous. Implementations will have to go through extra logic to process a packet with 'F' bit set I.e to know if it is a reflected packet or a response to the poll that is initiated. Don't see that. The only difference it to drop F-bit packets when you are about to reflect them - but the reflector is different code/hw anyway. Otherwise as mentioned above you have already today the situation of receiving F-bit packets while your are not in a Poll sequence (anymore). sigh, this kind of re-using a protocol always has risks and personally I still think we should introduce v2 BFD with 32 or 64 more bits in an otherwise unchanged header and stop spending time on these "clever protocol tricks". But then we won't proceed with S-BFD anymore and have long discussions about the new BFD v2 packet (risk of another "IPv6" with an uber-engineered protocol). So I understand nobody is keen on the v2 topic :-) Really not any good answer from my side other than we may have to look further for something else to "overload". Regards, Marc On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) wrote: Hello all, One comment inlined with GVP>. Thanks Prasad From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon) Sent: Monday, March 17, 2014 4:26 PM To: Sam Aldrin; Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Hi All, >From the discussions I understand that the following is the sequence being discussed: (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) Normal Sequence A to B: [p=3D0,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packets Timer negotiation (ack) A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll Timer negotiation (nack) Dueling poll A to B: [p=3D1,F=3D0] =3D=3D> ping packets B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll We have a few questions: 1. In the above P/F approach, we are still overloading the interpretation of 'F' bit. In our view this is same as re-interpreting/overloading 'D' bit. Don't the same arguments that we used against 'D' bit apply here too? 2. Most of the H/W based implementations use P/F bits to punt the received packets to S/W . Overloading P/F bits may impact H/W based implementations depending on these bits. GVP> Fully agree, I would prefer an option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to change. 3. 'F' bit itself is now ambiguous. Implementations will have to go through extra logic to process a packet with 'F' bit set I.e to know if it is a reflected packet or a response to the poll that is initiated. Thanks Regards Mallik From: Sam Aldrin > Date: Friday 14 March 2014 4:17 AM To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Comments inline. Sent from my iPad On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: Hi Jeff, Marc, BFDers, [Jeff wrote] So, I suppose the suggested addition to the S-BFD logic is "in the absence of a P-bit, F will still be set for security purposes upon reflection." This is certainly lesser evil than other evil ideas (especially v2 BFD), I'll take it :) S-BFD authors/collaborators & BFDers, comments? (speak now or forever hold your peace) Catching on this long email thread, finally. I too prefer not going v2 way, as it creates more complexity or open up many more issues. P/F bits as suggested by Jeff is a good option and we should use it. Base document should document on how those bits should be used, that includes any interval change. [Jeff wrote] If a reflector wants to tell an Initiator to slow down, it would simply need to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. So bit it. [Marc wrote] ah well, we simply don't have enough flags in the BFD packet. You are sure we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-) I am very sure :) [Marc wrote] But seriously: as the S-BFD sender is effectively talking to itself you do not need P/F to synchronize two systems. The reflector can simply set the Required Min RX Interval as it wants and the S-BFD sender adjusts. True that's definitely a possibility, but someone will surely argue that changing interval w/o presence of P bit will violate RFC5880. If it deviates from the way the P bit is presently being used, true. But if S-BFD could set rx interval differently to regular BFD as long as we document it right, we wouldn't be violating RFC5880, IMO. Do you think RFC is rigid about interval change? [Marc wrote] Also: as Jeff mentioned, without any "session state" on the reflector side it would be difficult to match any received F bit to a particular P sent out? With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector now. Reflector can still send [P=3D1, F=3D0], but that is one-way-communication/request. Nod. Sam -Nobo -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, March 13, 2014 4:28 PM To: Nobo Akiya (nobo) Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: I may be mis-remembering the conversation or mis-reading the document, but since the reflector is intended to be stateless why would it expect to receive a Final from the Initiator? It doesn't, reflector doesn't expect F bit (hence best effort). P bit will alert initiator that parameter has changed (i.e. Required Min RX Interval has changed). Remember that the primary reason for the Required Min RX Interval in regular BFD is that the receiver is also running a timer and will use that for its state by helping to adjust the sender's speed in a graceful fashion. In this case, graceful is important since only the Initiator cares about the actual timing of the packets. And even then, for our original scenario: A---M---B As long as each side doesn't respond to F packets (but sends them), I think we're still good. I think this means you can keep the poll bit idea to help suggest an Initiator to slow down and still prevent DoS. In such a scenario, M is injecting packets to A, with or without P, using B's addressing. Without P, A could still respond with F and B would drop it. So, I suppose the suggested addition to the S-BFD logic is "in the absence of a P-bit, F will still be set for security purposes upon reflection." If a reflector wants to tell an Initiator to slow down, it would simply need to inject an additional packet (perhaps a DoS on its own, so should be rate-limited) with the P bit set. This is effectively the "dueling poll" scenario that had popped up much earlier in standardization. -- Jeff --_000_CF4FB9891D024mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Marc,

Yes, that = was the original proposal. This was the original comment from Nobo for the = discriminator proposal:

"Deviating discriminator by reflector session - Proposed will prevent= a single S-BFD session to speak to multiple reflectors (cannot do reply demux'ing), if implementation wants to do this= or if there is ever such use-case." 

Even as pe= r the original proposal, each reflector can have its own local discriminato= r value allocated. So in theory, every reflector can have a different discr= iminator.
 
Nobo,

Any commen= ts?

Thanks

Regards
Mallik
From: Marc Binderberger <marc@sniff.de>
Date: Wednesday 19 March 2014 8:55 = PM
To: Cisco Employee <mmudigon@cisco.com>
Cc: "Nobo Akiya (nobo)" &= lt;nobo@cisco.com>, "Vengada = Prasad Govindan (venggovi)" <= venggovi@cisco.com>, "rtg-b= fd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Loop Prevention in S-B= FD (draft-akiya-bfd-seamless-base)

Hello Mallik,

we will see how the discussion goes although I personally do not think=
the M and D bit can be compared. Seems other people didn't see D a goo= d
fit (formally) either. Anyway, I'll have a look again at the "M&q= uot; bit
and the multipoint draft.


Regarding the discriminator usage for solving this, we do not want to =
put any specific restrictions on the way discriminators are used.

what restriction?

That's the reason the thread stopped there. Can't think of any
particular use case where MyDisc is used to demux, but that's the
reason not  to impose this restriction.

Huh?!  There is some misunderstanding here, so let me repeat= the
discriminator idea:

(1) S-BFD initiator R1 sends a BFD packet to reflector R2

(2) Reflector R2 copies the my_discr from incoming packet into
your_discr for outgoing packet.

(3) Reflector R2 copies one of his local discriminator values into
my_discr of the outgoing packet. This local discriminator is not a
"reflector discriminator" of R2.

(4) The S-BFD initiator R1 is doing normal BFD operations by looking <= /div>
into the your_discr of the reflected packet to demux.

Especially R1 is not using "my_discr" of the reflected packe= t to demux.

The point is: when someone is injecting an "endless loop" pa= cket by
using the "reflector discriminator" of R1 as my_discr, the r= eflector
discriminator of R2 as your_discr and sends the packet to R2 then the =
steps above result in a packet

   attacker -> R2 -> R1 -> R2 -> drop/punt

So after maximum 2 reflections the loop is broken.


Regards, Marc



On Wed, 19 Mar 2014 09:11:09 +0000, MALLIK MUDIGONDA (mmudigon) wr= ote:
Hi Marc,
Yes, as you said there are different ways of doing this. Since we
have a precedent for the 'M' bit getting updated in the latest
multi-point draft, we thought we will take the same route for our 'D' =
bit usage which is also, like your echo Rx interval filed, pretty
simple to implement.
Regarding the discriminator usage for solving this, we do not want to =
put any specific restrictions on the way discriminators are used.
That's the reason the thread stopped there. Can't think of any
particular use case where MyDisc is used to demux, but that's the
reason not  to impose this restriction.
Thanks
Regards
Mallik  
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
Date: Wednesday 19 March 2014 12:33 AM
To: Marc Binderberger <marc@sniff.= de>, "Vengada Prasad Govindan
(venggovi)" <venggovi@ci= sco.com>, Cisco Employee <m= mudigon@cisco.com>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
Hi Marc, et al,
Thanks for continued discussions on this topic.
Just wanted to let you and others know that few of us have been
studying how BFD-Multipoint draft updated RX procedures of RFC5880,
we should be able to provide an update to this thread soon.
BFD-Multipoint pointer:
-Nobo
-----Original Message-----
From: Marc Binderberger [mailto:marc@= sniff.de]
Sent: Tuesday, March 18, 2014 2:53 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA
(mmudigon); Nobo Akiya (nobo)
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
Hello Mallik, Prasad et al.,
okay, the following looks a bit weird. Maybe it is :-) On the other ha= nd it
avoids dealing with the "flags" which seem to either hit for= mal or
practical
problems.
The draft for S-BFD says ""Required Min Echo RX Interval&quo= t; SHOULD be zero.",
both for the originator and the reflector. Unless there is an idea
what "echo"
would mean for S-BFD (which is already pretty close to an echo functio= n
itself), what about re-using this field
(1) Initiator sets "Required Min Echo RX Interval" to zero
(2) Reflector sets "Required Min Echo RX Interval" to a non-= zero value
(3) the reflector is not reflecting a packet received with non-zero
"Required
Min Echo RX Interval"
Basically the flag idea, just a different field. As echo functionality=
is driven on the initiator side - the remote side only informs if it
allows and to what speed - I would not expect any adverse impact on th= e
initiator side, even when the whole functionality (i.e. the code) is
re-used for S-BFD on the initiator side. And RFC5880 doesn't put too
many restrictions on echo and "Required Min Echo RX Interval"= ;.
Feedback welcome :-)
Btw, what happened to the discriminator discussion?  If I re= call right
then the idea was the reflector is inserting a local discriminator int= o
the my_discr field when sending out the reflected packet. Nobo
mentioned this makes it impossible to differentiate reflectors - I
admit he lost me at this point ;-) Was this discussion conclusive?
No-Go for the discriminator idea?
Regards, Marc
On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote:
Hello Mallik and Prasad,

1.
In the above P/F approach, we are still overloading the
interpretation of 'F' bit. In our view this is same as
re-interpreting/overloading 'D' bit. Don't the same arguments that we<= /div>
used against 'D' bit apply here too?

what we discussed about the "D" bit was more on a formal lev= el. For "D"
is would be a replacement of what it means in RFC5880 and this is
formally kind of a no-no. At least difficult to change. The P/F bit us= e
for S-BFD should, as far as I can see, work smoothly with the existing=
RFC5880 interpretation.

Receiving F-bit set while you are not in a Poll sequence anymore is
what existing implementations - which we want to re-use largely on the=
S-BFD originator side - must support anyway.


2.
Most of the H/W based implementations use P/F bits to
punt the
received packets to S/W . Overloading P/F bits may impact H/W based
implementations depending on these bits.
GVP> Fully agree, I would prefer an option not re-interpreting or
overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA
assumptions that are hard to change.

Thanks for your feedback on this aspect :-)   I don't have a= ny good
answer here. It would mean on the S-BFD originator side the hw needs a=
differentiation based on the UDP port instead of simply re-using the
existing packet I/O. Or it needs at least a knob to suppress this F-bi= t
punting (which potentially breaks other things).


3.
'F' bit itself is now ambiguous. Implementations will have to
go
through extra logic to process a packet with 'F' bit set I.e to know
if it is a reflected packet or a response to the poll that is
initiated.

Don't see that. The only difference it to drop F-bit packets when you<= /div>
are about to reflect them - but the reflector is different code/hw
anyway. Otherwise as mentioned above you have already today the
situation of receiving F-bit packets while your are not in a Poll
sequence (anymore).


sigh, this kind of re-using a protocol always has risks and personally=
I still think we should introduce v2 BFD with 32 or 64 more bits in an=
otherwise unchanged header and stop spending time on these "cleve= r
protocol tricks". But then we won't proceed with S-BFD anymore an= d have
long discussions about the new BFD v2 packet (risk of another "IP= v6"
with an uber-engineered protocol). So I understand nobody is keen on
the v2 topic :-)


Really not any good answer from my side other than we may have to look=
further for something else to "overload".


Regards, Marc



On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (vengg= ovi)
wrote:
Hello all,
   One comment inlined with GVP>.
Thanks
Prasad

From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of MALLIK
MUDIGONDA (mmudigon)
Sent: Monday, March 17, 2014 4:26 PM
To: Sam Aldrin; Nobo Akiya (nobo)
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>

Hi All,

From the discussions I understand that the following is the sequence
being discussed:

(Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector)

Normal Sequence

A to B: [p=3D0,F=3D0] =3D=3D> ping packets
B to A: [p=3D0,F=3D1] =3D=3D> pong packets

Timer negotiation (ack)

A to B: [p=3D1,F=3D0] =3D=3D> ping packets
B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll

Timer negotiation (nack) Dueling poll

A to B: [p=3D1,F=3D0] =3D=3D> ping packets
B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll
B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll

We have a few questions:

1.
In the above P/F approach, we are still overloading the
interpretation of 'F' bit. In our view this is same as
re-interpreting/overloading 'D' bit. Don't the same arguments that we<= /div>
used against 'D' bit apply here too?
2.
Most of the H/W based implementations use P/F bits to
punt the
received packets to S/W . Overloading P/F bits may impact H/W based
implementations depending on these bits.
GVP> Fully agree, I would prefer an option not re-interpreting or
overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA
assumptions that are hard to change.
3.
'F' bit itself is now ambiguous. Implementations will have to
go
through extra logic to process a packet with 'F' bit set I.e to know
if it is a reflected packet or a response to the poll that is
initiated.
  Thanks

Regards
Mallik
From: Sam Aldrin <aldrin.i= etf@gmail.com>
Date: Friday 14 March 2014 4:17 AM
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>

Comments inline.

Sent from my iPad

On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" <nobo@cisco.com>
wrote:
Hi Jeff, Marc, BFDers,
[Jeff wrote]
So, I suppose the suggested addition to the S-BFD logic is "in th= e
absence of
a P-bit, F will still be set for security purposes upon reflection.&qu= ot;
This  is certainly lesser evil than other evil ideas (especi= ally v2
BFD), I'll take it :)
S-BFD authors/collaborators & BFDers, comments?
(speak now or forever hold your peace)
Catching on this long email thread, finally.

I too prefer not going v2 way, as it creates more complexity or open
up many more issues.
P/F bits as suggested by Jeff is a good option and we should use it.
Base document should document on how those bits should be used, that
includes any interval change.
[Jeff wrote]
If a reflector wants to tell an Initiator to slow down, it would
simply need to
inject an additional packet (perhaps a DoS on its own, so should be
rate-limited) with the P bit set.  This is effectively the <= /div>
"dueling poll"
scenario that had popped up much earlier in standardization.
So bit it.
[Marc wrote]
ah well, we simply don't have enough flags in the BFD packet. You
are sure
we don't want a BFD "v2" to add another 32/64 bit for future= flag
use? ;-)
I am very sure :)
[Marc wrote]
But seriously: as the S-BFD sender is effectively talking to itself
you do not
need P/F to synchronize two systems. The reflector can simply set the<= /div>
Required Min RX Interval as it wants and the S-BFD sender adjusts.
True that's definitely a possibility, but someone will surely argue
that changing interval w/o presence of P bit will violate RFC5880.
If it deviates from the way the P bit is presently being used, true.
But if S-BFD could set rx interval differently to regular BFD as long<= /div>
as we document it right, we wouldn't  be violating RFC5880, = IMO. Do
you think RFC is rigid about interval change?
[Marc wrote]
Also: as Jeff mentioned, without any "session state" on the<= /div>
reflector side it
would be difficult to match any received F bit to a particular P
sent out?
With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector=
now. Reflector can still send [P=3D1, F=3D0], but that is
one-way-communication/request.

Nod.

Sam
-Nobo
-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfr= c.org]
Sent: Thursday, March 13, 2014 4:28 PM
To: Nobo Akiya (nobo)
Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)<= /div>
On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote:=
I may be mis-remembering the conversation or mis-reading the
document, but since the reflector is intended to be stateless why
would it expect to receive a Final from the Initiator?
It doesn't, reflector doesn't expect F bit (hence best effort). P
bit will alert
initiator that parameter has changed (i.e. Required Min RX
Interval has
changed).
Remember that the primary reason for the Required Min RX Interval in
regular BFD is that the receiver is also running a timer and will
use that for
its state by helping to adjust the sender's speed in a graceful
fashion.
In this case, graceful is important since only the Initiator cares
about the
actual timing of the packets.
And even then, for our original scenario:
A---M---B
As long as each side doesn't respond to F packets (but sends them),
I think
we're still good.  I think this means you can keep the poll = bit
idea to help
suggest an Initiator to slow down and still prevent DoS.  In= such a
scenario, M
is injecting packets to A, with or without P, using B's
addressing.  Without P,
A could still respond with F and B would drop it.
So, I suppose the suggested addition to the S-BFD logic is "in th= e
absence of
a P-bit, F will still be set for security purposes upon reflection.&qu= ot;
If a reflector wants to tell an Initiator to slow down, it would
simply need to
inject an additional packet (perhaps a DoS on its own, so should be
rate-limited) with the P bit set.  This is effectively the <= /div>
"dueling poll"
scenario that had popped up much earlier in standardization.
-- Jeff





--_000_CF4FB9891D024mmudigonciscocom_-- From nobody Wed Mar 19 09:37:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF2C1A0412 for ; Wed, 19 Mar 2014 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8bZUUVIjlPZ for ; Wed, 19 Mar 2014 09:37:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC2B1A06EE for ; Wed, 19 Mar 2014 09:37:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A6954C17E; Wed, 19 Mar 2014 12:37:39 -0400 (EDT) Date: Wed, 19 Mar 2014 12:37:39 -0400 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: BFD v2? Message-ID: <20140319163739.GB30410@pfrc> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/JNVfEsYGZMdWWtkCoHHe4fAwQEY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 16:37:50 -0000 On Wed, Mar 19, 2014 at 04:46:40AM +0000, Bhatia, Manav (Manav) wrote: > All I am saying is that we should not bump the version # till we have a > use case where we cant work with the existing fields at all and the change > required is so radical that upping the version # is the only recourse > left. This largely reflects my opinion. The second half of that opinion is "send at wire rate". In the life of BFD, we've successfully resisted and engineered our way around the urge to extend it for various things to keep the core use cases of the protocol. Once we can no longer do that, then it's time to look at bumping the version. I'm not convinced the s-bfd stuff has pushed us there quite yet. -- Jeff From nobody Wed Mar 19 09:38:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A151A06DA for ; Wed, 19 Mar 2014 09:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.748 X-Spam-Level: X-Spam-Status: No, score=-7.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyGrHKTNswGf for ; Wed, 19 Mar 2014 09:38:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 219111A0412 for ; Wed, 19 Mar 2014 09:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17004; q=dns/txt; s=iport; t=1395247109; x=1396456709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=clLhyVW8d0j9eoo7pBGT5Drk175xD6WDj6bNo3g6/GU=; b=mqr/wIxFq0ARMlzWSdx7DJmoKh4sGLXjTdB9tMINayaCeUXGFInMwpJJ xwmJNfYnJjH/dDIDcNk4pwbQN8SfX4d4s4VrWYkq0RXF6ZRTsgF9j42VH BPnqP31795N6JjSPc3SozeFZqwTffDF4aa5mVy2KKxdQQAwFELqS3oux+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAAHHKVOtJV2c/2dsb2JhbABagmUhO1eqMpgTgRoWdIIlAQEBBCdSDAQCAQgRAwEBAQEKHQchERQJCAIEAQ0FCIddAxEBDMgxDYcSF4xNgTYKAQYBHzEHBoMegRQEiRqNQIMfizaFSIMtgWkBCBci X-IronPort-AV: E=Sophos;i="4.97,686,1389744000"; d="scan'208";a="28710887" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 19 Mar 2014 16:38:28 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2JGcSUO020696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 16:38:28 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.03.0123.003; Wed, 19 Mar 2014 11:38:28 -0500 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAGSXAIAArtZA Date: Wed, 19 Mar 2014 16:38:27 +0000 Message-ID: References: <20140319082501342601.778988ca@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Tb1poOeq0psfIcaZb_f4GcX3JkI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 16:38:41 -0000 The protocol pieces of S-BFD is in three folds: 1. Discriminator mapping/advertisement. 2. Reflector session procedures. 3. Procedures to interact with reflector session. As long as S-BFD initiator implementation conforms to (3), the rest of S-BF= D initiator behaviors are not bound by the protocol, i.e. one is free to us= e the S-BFD "infrastructure" in any way (i.e. when to start, stop, slow dow= n, round-robin a set of paths, monitor set of [same, diff] targets which re= sults are fed into specific algorithm, whatever it may be). Imagine a netwo= rk with S-BFD, be it IP, MPLS or SR. Every network node has reflector(s) an= d every network node knows discriminator(s) of other reflector(s). In such = network, one is really free to implement all sorts of S-BFD initiator(s) ..= . based on specific [existing, new] use-cases and customer demands. Deviating discriminator approach ... technically fine, but I prefer not to = go with it as it can limit S-BFD initiator freedom which may cost us a lot = more in long term. =09 -Nobo > -----Original Message----- > From: MALLIK MUDIGONDA (mmudigon) > Sent: Wednesday, March 19, 2014 11:55 AM > To: Marc Binderberger > Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi Marc, >=20 > Yes, that was the original proposal. This was the original comment from > Nobo for the discriminator proposal: >=20 > "Deviating discriminator by reflector session - Proposed will prevent a > single S-BFD session to speak to multiple reflectors (cannot do reply > demux'ing), if implementation wants to do this or if there is ever such u= se- > case." >=20 > Even as per the original proposal, each reflector can have its own local > discriminator value allocated. So in theory, every reflector can have a > different discriminator. >=20 > Nobo, >=20 > Any comments? >=20 > Thanks >=20 > Regards > Mallik > From: Marc Binderberger > Date: Wednesday 19 March 2014 8:55 PM > To: Cisco Employee > Cc: "Nobo Akiya (nobo)" , "Vengada Prasad Govindan > (venggovi)" , "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello Mallik, >=20 > we will see how the discussion goes although I personally do not think > the M and D bit can be compared. Seems other people didn't see D a good > fit (formally) either. Anyway, I'll have a look again at the "M" bit > and the multipoint draft. >=20 >=20 > Regarding the discriminator usage for solving this, we do not want to > put any specific restrictions on the way discriminators are used. >=20 > what restriction? >=20 > That's the reason the thread stopped there. Can't think of any > particular use case where MyDisc is used to demux, but that's the > reason not=A0=A0to impose this restriction. >=20 > Huh?!=A0=A0There is some misunderstanding here, so let me repeat the > discriminator idea: >=20 > (1) S-BFD initiator R1 sends a BFD packet to reflector R2 >=20 > (2) Reflector R2 copies the my_discr from incoming packet into > your_discr for outgoing packet. >=20 > (3) Reflector R2 copies one of his local discriminator values into > my_discr of the outgoing packet. This local discriminator is not a > "reflector discriminator" of R2. >=20 > (4) The S-BFD initiator R1 is doing normal BFD operations by looking > into the your_discr of the reflected packet to demux. >=20 > Especially R1 is not using "my_discr" of the reflected packet to demux. >=20 > The point is: when someone is injecting an "endless loop" packet by > using the "reflector discriminator" of R1 as my_discr, the reflector > discriminator of R2 as your_discr and sends the packet to R2 then the > steps above result in a packet >=20 > =A0=A0 attacker -> R2 -> R1 -> R2 -> drop/punt >=20 > So after maximum 2 reflections the loop is broken. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Wed, 19 Mar 2014 09:11:09 +0000, MALLIK MUDIGONDA (mmudigon) > wrote: > Hi Marc, > Yes, as you said there are different ways of doing this. Since we > have a precedent for the 'M' bit getting updated in the latest > multi-point draft, we thought we will take the same route for our 'D' > bit usage which is also, like your echo Rx interval filed, pretty > simple to implement. > Regarding the discriminator usage for solving this, we do not want to > put any specific restrictions on the way discriminators are used. > That's the reason the thread stopped there. Can't think of any > particular use case where MyDisc is used to demux, but that's the > reason not=A0=A0to impose this restriction. > Thanks > Regards > Mallik > From: "Nobo Akiya (nobo)" > Date: Wednesday 19 March 2014 12:33 AM > To: Marc Binderberger , "Vengada Prasad Govindan > (venggovi)" , Cisco Employee > > Cc: "rtg-bfd@ietf.org" > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > Hi Marc, et al, > Thanks for continued discussions on this topic. > Just wanted to let you and others know that few of us have been > studying how BFD-Multipoint draft updated RX procedures of RFC5880, > we should be able to provide an update to this thread soon. > BFD-Multipoint pointer: > http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text= =3D1 > -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, March 18, 2014 2:53 PM > To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA > (mmudigon); Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > Hello Mallik, Prasad et al., > okay, the following looks a bit weird. Maybe it is :-) On the other hand = it > avoids dealing with the "flags" which seem to either hit formal or > practical > problems. > The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.= ", > both for the originator and the reflector. Unless there is an idea > what "echo" > would mean for S-BFD (which is already pretty close to an echo function > itself), what about re-using this field > (1) Initiator sets "Required Min Echo RX Interval" to zero > (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value > (3) the reflector is not reflecting a packet received with non-zero > "Required > Min Echo RX Interval" > Basically the flag idea, just a different field. As echo functionality > is driven on the initiator side - the remote side only informs if it > allows and to what speed - I would not expect any adverse impact on the > initiator side, even when the whole functionality (i.e. the code) is > re-used for S-BFD on the initiator side. And RFC5880 doesn't put too > many restrictions on echo and "Required Min Echo RX Interval". > Feedback welcome :-) > Btw, what happened to the discriminator discussion?=A0=A0If I recall righ= t > then the idea was the reflector is inserting a local discriminator into > the my_discr field when sending out the reflected packet. Nobo > mentioned this makes it impossible to differentiate reflectors - I > admit he lost me at this point ;-) Was this discussion conclusive? > No-Go for the discriminator idea? > Regards, Marc > On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: > Hello Mallik and Prasad, >=20 > 1. > In the above P/F approach, we are still overloading the > interpretation of 'F' bit. In our view this is same as > re-interpreting/overloading 'D' bit. Don't the same arguments that we > used against 'D' bit apply here too? >=20 > what we discussed about the "D" bit was more on a formal level. For "D" > is would be a replacement of what it means in RFC5880 and this is > formally kind of a no-no. At least difficult to change. The P/F bit use > for S-BFD should, as far as I can see, work smoothly with the existing > RFC5880 interpretation. >=20 > Receiving F-bit set while you are not in a Poll sequence anymore is > what existing implementations - which we want to re-use largely on the > S-BFD originator side - must support anyway. >=20 >=20 > 2. > Most of the H/W based implementations use P/F bits to > punt the > received packets to S/W . Overloading P/F bits may impact H/W based > implementations depending on these bits. > GVP> Fully agree, I would prefer an option not re-interpreting or > overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > assumptions that are hard to change. >=20 > Thanks for your feedback on this aspect :-)=A0=A0 I don't have any good > answer here. It would mean on the S-BFD originator side the hw needs a > differentiation based on the UDP port instead of simply re-using the > existing packet I/O. Or it needs at least a knob to suppress this F-bit > punting (which potentially breaks other things). >=20 >=20 > 3. > 'F' bit itself is now ambiguous. Implementations will have to > go > through extra logic to process a packet with 'F' bit set I.e to know > if it is a reflected packet or a response to the poll that is > initiated. >=20 > Don't see that. The only difference it to drop F-bit packets when you > are about to reflect them - but the reflector is different code/hw > anyway. Otherwise as mentioned above you have already today the > situation of receiving F-bit packets while your are not in a Poll > sequence (anymore). >=20 >=20 > sigh, this kind of re-using a protocol always has risks and personally > I still think we should introduce v2 BFD with 32 or 64 more bits in an > otherwise unchanged header and stop spending time on these "clever > protocol tricks". But then we won't proceed with S-BFD anymore and have > long discussions about the new BFD v2 packet (risk of another "IPv6" > with an uber-engineered protocol). So I understand nobody is keen on > the v2 topic :-) >=20 >=20 > Really not any good answer from my side other than we may have to look > further for something else to "overload". >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) > wrote: > Hello all, > =A0=A0 One comment inlined with GVP>. > Thanks > Prasad >=20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK > MUDIGONDA (mmudigon) > Sent: Monday, March 17, 2014 4:26 PM > To: Sam Aldrin; Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hi All, >=20 > From the discussions I understand that the following is the sequence > being discussed: >=20 > (Initiator)A=3D=3D=3D=3D=3DM=3D=3D=3D=3D=3DB(Reflector) >=20 > Normal Sequence >=20 > A to B: [p=3D0,F=3D0] =3D=3D> ping packets > B to A: [p=3D0,F=3D1] =3D=3D> pong packets >=20 > Timer negotiation (ack) >=20 > A to B: [p=3D1,F=3D0] =3D=3D> ping packets > B to A: [p=3D0,F=3D1] =3D=3D> pong packet with ack for timer poll >=20 > Timer negotiation (nack) Dueling poll >=20 > A to B: [p=3D1,F=3D0] =3D=3D> ping packets > B to A: [p=3D0.F=3D1] =3D=3D> pong packet with ack for timer poll > B to A: [p=3D1,F=3D0] =3D=3D> Reflector initiated poll >=20 > We have a few questions: >=20 > 1. > In the above P/F approach, we are still overloading the > interpretation of 'F' bit. In our view this is same as > re-interpreting/overloading 'D' bit. Don't the same arguments that we > used against 'D' bit apply here too? > 2. > Most of the H/W based implementations use P/F bits to > punt the > received packets to S/W . Overloading P/F bits may impact H/W based > implementations depending on these bits. > GVP> Fully agree, I would prefer an option not re-interpreting or > overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA > assumptions that are hard to change. > 3. > 'F' bit itself is now ambiguous. Implementations will have to > go > through extra logic to process a packet with 'F' bit set I.e to know > if it is a reflected packet or a response to the poll that is > initiated. > =A0=A0Thanks >=20 > Regards > Mallik > From: Sam Aldrin > Date: Friday 14 March 2014 4:17 AM > To: "Nobo Akiya (nobo)" > Cc: "rtg-bfd@ietf.org" > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Comments inline. >=20 > Sent from my iPad >=20 > On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" > wrote: > Hi Jeff, Marc, BFDers, > [Jeff wrote] > So, I suppose the suggested addition to the S-BFD logic is "in the > absence of > a P-bit, F will still be set for security purposes upon reflection." > This=A0=A0is certainly lesser evil than other evil ideas (especially v2 > BFD), I'll take it :) > S-BFD authors/collaborators & BFDers, comments? > (speak now or forever hold your peace) > Catching on this long email thread, finally. >=20 > I too prefer not going v2 way, as it creates more complexity or open > up many more issues. > P/F bits as suggested by Jeff is a good option and we should use it. > Base document should document on how those bits should be used, that > includes any interval change. > [Jeff wrote] > If a reflector wants to tell an Initiator to slow down, it would > simply need to > inject an additional packet (perhaps a DoS on its own, so should be > rate-limited) with the P bit set.=A0=A0This is effectively the > "dueling poll" > scenario that had popped up much earlier in standardization. > So bit it. > [Marc wrote] > ah well, we simply don't have enough flags in the BFD packet. You > are sure > we don't want a BFD "v2" to add another 32/64 bit for future flag > use? ;-) > I am very sure :) > [Marc wrote] > But seriously: as the S-BFD sender is effectively talking to itself > you do not > need P/F to synchronize two systems. The reflector can simply set the > Required Min RX Interval as it wants and the S-BFD sender adjusts. > True that's definitely a possibility, but someone will surely argue > that changing interval w/o presence of P bit will violate RFC5880. > If it deviates from the way the P bit is presently being used, true. > But if S-BFD could set rx interval differently to regular BFD as long > as we document it right, we wouldn't=A0=A0be violating RFC5880, IMO. Do > you think RFC is rigid about interval change? > [Marc wrote] > Also: as Jeff mentioned, without any "session state" on the > reflector side it > would be difficult to match any received F bit to a particular P > sent out? > With new proposal by Jeff, [P=3D0, F=3D1] will be dropped by reflector > now. Reflector can still send [P=3D1, F=3D0], but that is > one-way-communication/request. >=20 > Nod. >=20 > Sam > -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, March 13, 2014 4:28 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: > I may be mis-remembering the conversation or mis-reading the > document, but since the reflector is intended to be stateless why > would it expect to receive a Final from the Initiator? > It doesn't, reflector doesn't expect F bit (hence best effort). P > bit will alert > initiator that parameter has changed (i.e. Required Min RX > Interval has > changed). > Remember that the primary reason for the Required Min RX Interval in > regular BFD is that the receiver is also running a timer and will > use that for > its state by helping to adjust the sender's speed in a graceful > fashion. > In this case, graceful is important since only the Initiator cares > about the > actual timing of the packets. > And even then, for our original scenario: > A---M---B > As long as each side doesn't respond to F packets (but sends them), > I think > we're still good.=A0=A0I think this means you can keep the poll bit > idea to help > suggest an Initiator to slow down and still prevent DoS.=A0=A0In such a > scenario, M > is injecting packets to A, with or without P, using B's > addressing.=A0=A0Without P, > A could still respond with F and B would drop it. > So, I suppose the suggested addition to the S-BFD logic is "in the > absence of > a P-bit, F will still be set for security purposes upon reflection." > If a reflector wants to tell an Initiator to slow down, it would > simply need to > inject an additional packet (perhaps a DoS on its own, so should be > rate-limited) with the P bit set.=A0=A0This is effectively the > "dueling poll" > scenario that had popped up much earlier in standardization. > -- Jeff >=20 >=20 >=20 >=20 From nobody Wed Mar 19 10:55:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166521A07A2 for ; Wed, 19 Mar 2014 10:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2J1fMi3a38H for ; Wed, 19 Mar 2014 10:55:07 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8151A0779 for ; Wed, 19 Mar 2014 10:55:06 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 024F52AA0F; Wed, 19 Mar 2014 17:54:55 +0000 (GMT) Date: Wed, 19 Mar 2014 10:55:02 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140319105502166172.9cba3db9@sniff.de> In-Reply-To: References: <20140319082501342601.778988ca@sniff.de> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/1Lz8OMjXMa59nBSOdc2eWnrVpdo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 17:55:10 -0000 Hello Nobo, > Deviating discriminator approach ... technically fine, but I prefer > not to go with it as it can limit S-BFD initiator freedom which may > cost us a lot more in long term. sorry but this is just too vague. The initiator receives back his own discriminator as your_disc in the incoming packet and that should be enough. You have a different session or destination or whatever else is different - give it a unique local discriminator to separate it. The my_discr field never had much meaning for the receiving BFD entity and this worked great for BFD as a general rule. Regards, Marc On Wed, 19 Mar 2014 16:38:27 +0000, Nobo Akiya (nobo) wrote: > > The protocol pieces of S-BFD is in three folds: > 1. Discriminator mapping/advertisement. > 2. Reflector session procedures. > 3. Procedures to interact with reflector session. > > As long as S-BFD initiator implementation conforms to (3), the rest > of S-BFD initiator behaviors are not bound by the protocol, i.e. one > is free to use the S-BFD "infrastructure" in any way (i.e. when to > start, stop, slow down, round-robin a set of paths, monitor set of > [same, diff] targets which results are fed into specific algorithm, > whatever it may be). Imagine a network with S-BFD, be it IP, MPLS or > SR. Every network node has reflector(s) and every network node knows > discriminator(s) of other reflector(s). In such network, one is > really free to implement all sorts of S-BFD initiator(s) ... based on > specific [existing, new] use-cases and customer demands. > > Deviating discriminator approach ... technically fine, but I prefer > not to go with it as it can limit S-BFD initiator freedom which may > cost us a lot more in long term. > > -Nobo > >> -----Original Message----- >> From: MALLIK MUDIGONDA (mmudigon) >> Sent: Wednesday, March 19, 2014 11:55 AM >> To: Marc Binderberger >> Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- >> bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hi Marc, >> >> Yes, that was the original proposal. This was the original comment from >> Nobo for the discriminator proposal: >> >> "Deviating discriminator by reflector session - Proposed will prevent a >> single S-BFD session to speak to multiple reflectors (cannot do reply >> demux'ing), if implementation wants to do this or if there is ever >> such use- >> case." >> >> Even as per the original proposal, each reflector can have its own local >> discriminator value allocated. So in theory, every reflector can have a >> different discriminator. >> >> Nobo, >> >> Any comments? >> >> Thanks >> >> Regards >> Mallik >> From: Marc Binderberger >> Date: Wednesday 19 March 2014 8:55 PM >> To: Cisco Employee >> Cc: "Nobo Akiya (nobo)" , "Vengada Prasad Govindan >> (venggovi)" , "rtg-bfd@ietf.org" >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hello Mallik, >> >> we will see how the discussion goes although I personally do not think >> the M and D bit can be compared. Seems other people didn't see D a good >> fit (formally) either. Anyway, I'll have a look again at the "M" bit >> and the multipoint draft. >> >> >> Regarding the discriminator usage for solving this, we do not want to >> put any specific restrictions on the way discriminators are used. >> >> what restriction? >> >> That's the reason the thread stopped there. Can't think of any >> particular use case where MyDisc is used to demux, but that's the >> reason not to impose this restriction. >> >> Huh?! There is some misunderstanding here, so let me repeat the >> discriminator idea: >> >> (1) S-BFD initiator R1 sends a BFD packet to reflector R2 >> >> (2) Reflector R2 copies the my_discr from incoming packet into >> your_discr for outgoing packet. >> >> (3) Reflector R2 copies one of his local discriminator values into >> my_discr of the outgoing packet. This local discriminator is not a >> "reflector discriminator" of R2. >> >> (4) The S-BFD initiator R1 is doing normal BFD operations by looking >> into the your_discr of the reflected packet to demux. >> >> Especially R1 is not using "my_discr" of the reflected packet to demux. >> >> The point is: when someone is injecting an "endless loop" packet by >> using the "reflector discriminator" of R1 as my_discr, the reflector >> discriminator of R2 as your_discr and sends the packet to R2 then the >> steps above result in a packet >> >> attacker -> R2 -> R1 -> R2 -> drop/punt >> >> So after maximum 2 reflections the loop is broken. >> >> >> Regards, Marc >> >> >> >> On Wed, 19 Mar 2014 09:11:09 +0000, MALLIK MUDIGONDA (mmudigon) >> wrote: >> Hi Marc, >> Yes, as you said there are different ways of doing this. Since we >> have a precedent for the 'M' bit getting updated in the latest >> multi-point draft, we thought we will take the same route for our 'D' >> bit usage which is also, like your echo Rx interval filed, pretty >> simple to implement. >> Regarding the discriminator usage for solving this, we do not want to >> put any specific restrictions on the way discriminators are used. >> That's the reason the thread stopped there. Can't think of any >> particular use case where MyDisc is used to demux, but that's the >> reason not to impose this restriction. >> Thanks >> Regards >> Mallik >> From: "Nobo Akiya (nobo)" >> Date: Wednesday 19 March 2014 12:33 AM >> To: Marc Binderberger , "Vengada Prasad Govindan >> (venggovi)" , Cisco Employee >> >> Cc: "rtg-bfd@ietf.org" >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> Hi Marc, et al, >> Thanks for continued discussions on this topic. >> Just wanted to let you and others know that few of us have been >> studying how BFD-Multipoint draft updated RX procedures of RFC5880, >> we should be able to provide an update to this thread soon. >> BFD-Multipoint pointer: >> http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=1 >> -Nobo >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Tuesday, March 18, 2014 2:53 PM >> To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA >> (mmudigon); Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> Hello Mallik, Prasad et al., >> okay, the following looks a bit weird. Maybe it is :-) On the other hand it >> avoids dealing with the "flags" which seem to either hit formal or >> practical >> problems. >> The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.", >> both for the originator and the reflector. Unless there is an idea >> what "echo" >> would mean for S-BFD (which is already pretty close to an echo function >> itself), what about re-using this field >> (1) Initiator sets "Required Min Echo RX Interval" to zero >> (2) Reflector sets "Required Min Echo RX Interval" to a non-zero value >> (3) the reflector is not reflecting a packet received with non-zero >> "Required >> Min Echo RX Interval" >> Basically the flag idea, just a different field. As echo functionality >> is driven on the initiator side - the remote side only informs if it >> allows and to what speed - I would not expect any adverse impact on the >> initiator side, even when the whole functionality (i.e. the code) is >> re-used for S-BFD on the initiator side. And RFC5880 doesn't put too >> many restrictions on echo and "Required Min Echo RX Interval". >> Feedback welcome :-) >> Btw, what happened to the discriminator discussion? If I recall right >> then the idea was the reflector is inserting a local discriminator into >> the my_discr field when sending out the reflected packet. Nobo >> mentioned this makes it impossible to differentiate reflectors - I >> admit he lost me at this point ;-) Was this discussion conclusive? >> No-Go for the discriminator idea? >> Regards, Marc >> On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote: >> Hello Mallik and Prasad, >> >> 1. >> In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that we >> used against 'D' bit apply here too? >> >> what we discussed about the "D" bit was more on a formal level. For "D" >> is would be a replacement of what it means in RFC5880 and this is >> formally kind of a no-no. At least difficult to change. The P/F bit use >> for S-BFD should, as far as I can see, work smoothly with the existing >> RFC5880 interpretation. >> >> Receiving F-bit set while you are not in a Poll sequence anymore is >> what existing implementations - which we want to re-use largely on the >> S-BFD originator side - must support anyway. >> >> >> 2. >> Most of the H/W based implementations use P/F bits to >> punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. >> >> Thanks for your feedback on this aspect :-) I don't have any good >> answer here. It would mean on the S-BFD originator side the hw needs a >> differentiation based on the UDP port instead of simply re-using the >> existing packet I/O. Or it needs at least a knob to suppress this F-bit >> punting (which potentially breaks other things). >> >> >> 3. >> 'F' bit itself is now ambiguous. Implementations will have to >> go >> through extra logic to process a packet with 'F' bit set I.e to know >> if it is a reflected packet or a response to the poll that is >> initiated. >> >> Don't see that. The only difference it to drop F-bit packets when you >> are about to reflect them - but the reflector is different code/hw >> anyway. Otherwise as mentioned above you have already today the >> situation of receiving F-bit packets while your are not in a Poll >> sequence (anymore). >> >> >> sigh, this kind of re-using a protocol always has risks and personally >> I still think we should introduce v2 BFD with 32 or 64 more bits in an >> otherwise unchanged header and stop spending time on these "clever >> protocol tricks". But then we won't proceed with S-BFD anymore and have >> long discussions about the new BFD v2 packet (risk of another "IPv6" >> with an uber-engineered protocol). So I understand nobody is keen on >> the v2 topic :-) >> >> >> Really not any good answer from my side other than we may have to look >> further for something else to "overload". >> >> >> Regards, Marc >> >> >> >> On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) >> wrote: >> Hello all, >> One comment inlined with GVP>. >> Thanks >> Prasad >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK >> MUDIGONDA (mmudigon) >> Sent: Monday, March 17, 2014 4:26 PM >> To: Sam Aldrin; Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Hi All, >> >> From the discussions I understand that the following is the sequence >> being discussed: >> >> (Initiator)A=====M=====B(Reflector) >> >> Normal Sequence >> >> A to B: [p=0,F=0] ==> ping packets >> B to A: [p=0,F=1] ==> pong packets >> >> Timer negotiation (ack) >> >> A to B: [p=1,F=0] ==> ping packets >> B to A: [p=0,F=1] ==> pong packet with ack for timer poll >> >> Timer negotiation (nack) Dueling poll >> >> A to B: [p=1,F=0] ==> ping packets >> B to A: [p=0.F=1] ==> pong packet with ack for timer poll >> B to A: [p=1,F=0] ==> Reflector initiated poll >> >> We have a few questions: >> >> 1. >> In the above P/F approach, we are still overloading the >> interpretation of 'F' bit. In our view this is same as >> re-interpreting/overloading 'D' bit. Don't the same arguments that we >> used against 'D' bit apply here too? >> 2. >> Most of the H/W based implementations use P/F bits to >> punt the >> received packets to S/W . Overloading P/F bits may impact H/W based >> implementations depending on these bits. >> GVP> Fully agree, I would prefer an option not re-interpreting or >> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA >> assumptions that are hard to change. >> 3. >> 'F' bit itself is now ambiguous. Implementations will have to >> go >> through extra logic to process a packet with 'F' bit set I.e to know >> if it is a reflected packet or a response to the poll that is >> initiated. >> Thanks >> >> Regards >> Mallik >> From: Sam Aldrin >> Date: Friday 14 March 2014 4:17 AM >> To: "Nobo Akiya (nobo)" >> Cc: "rtg-bfd@ietf.org" >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Comments inline. >> >> Sent from my iPad >> >> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" >> wrote: >> Hi Jeff, Marc, BFDers, >> [Jeff wrote] >> So, I suppose the suggested addition to the S-BFD logic is "in the >> absence of >> a P-bit, F will still be set for security purposes upon reflection." >> This is certainly lesser evil than other evil ideas (especially v2 >> BFD), I'll take it :) >> S-BFD authors/collaborators & BFDers, comments? >> (speak now or forever hold your peace) >> Catching on this long email thread, finally. >> >> I too prefer not going v2 way, as it creates more complexity or open >> up many more issues. >> P/F bits as suggested by Jeff is a good option and we should use it. >> Base document should document on how those bits should be used, that >> includes any interval change. >> [Jeff wrote] >> If a reflector wants to tell an Initiator to slow down, it would >> simply need to >> inject an additional packet (perhaps a DoS on its own, so should be >> rate-limited) with the P bit set. This is effectively the >> "dueling poll" >> scenario that had popped up much earlier in standardization. >> So bit it. >> [Marc wrote] >> ah well, we simply don't have enough flags in the BFD packet. You >> are sure >> we don't want a BFD "v2" to add another 32/64 bit for future flag >> use? ;-) >> I am very sure :) >> [Marc wrote] >> But seriously: as the S-BFD sender is effectively talking to itself >> you do not >> need P/F to synchronize two systems. The reflector can simply set the >> Required Min RX Interval as it wants and the S-BFD sender adjusts. >> True that's definitely a possibility, but someone will surely argue >> that changing interval w/o presence of P bit will violate RFC5880. >> If it deviates from the way the P bit is presently being used, true. >> But if S-BFD could set rx interval differently to regular BFD as long >> as we document it right, we wouldn't be violating RFC5880, IMO. Do >> you think RFC is rigid about interval change? >> [Marc wrote] >> Also: as Jeff mentioned, without any "session state" on the >> reflector side it >> would be difficult to match any received F bit to a particular P >> sent out? >> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector >> now. Reflector can still send [P=1, F=0], but that is >> one-way-communication/request. >> >> Nod. >> >> Sam >> -Nobo >> -----Original Message----- >> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >> Sent: Thursday, March 13, 2014 4:28 PM >> To: Nobo Akiya (nobo) >> Cc: Jeffrey Haas; Marc Binderberger; rtg-bfd@ietf.org >> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote: >> I may be mis-remembering the conversation or mis-reading the >> document, but since the reflector is intended to be stateless why >> would it expect to receive a Final from the Initiator? >> It doesn't, reflector doesn't expect F bit (hence best effort). P >> bit will alert >> initiator that parameter has changed (i.e. Required Min RX >> Interval has >> changed). >> Remember that the primary reason for the Required Min RX Interval in >> regular BFD is that the receiver is also running a timer and will >> use that for >> its state by helping to adjust the sender's speed in a graceful >> fashion. >> In this case, graceful is important since only the Initiator cares >> about the >> actual timing of the packets. >> And even then, for our original scenario: >> A---M---B >> As long as each side doesn't respond to F packets (but sends them), >> I think >> we're still good. I think this means you can keep the poll bit >> idea to help >> suggest an Initiator to slow down and still prevent DoS. In such a >> scenario, M >> is injecting packets to A, with or without P, using B's >> addressing. Without P, >> A could still respond with F and B would drop it. >> So, I suppose the suggested addition to the S-BFD logic is "in the >> absence of >> a P-bit, F will still be set for security purposes upon reflection." >> If a reflector wants to tell an Initiator to slow down, it would >> simply need to >> inject an additional packet (perhaps a DoS on its own, so should be >> rate-limited) with the P bit set. This is effectively the >> "dueling poll" >> scenario that had popped up much earlier in standardization. >> -- Jeff >> >> >> >> > From nobody Wed Mar 19 17:01:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E17D1A0834 for ; Wed, 19 Mar 2014 17:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3I_U8SBdSKL for ; Wed, 19 Mar 2014 17:01:06 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA591A0827 for ; Wed, 19 Mar 2014 17:01:06 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s2K00mpc025008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Mar 2014 19:00:49 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s2K00lwJ030910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 20:00:47 -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; Wed, 19 Mar 2014 20:00:47 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Thu, 20 Mar 2014 08:00:43 +0800 From: "Bhatia, Manav (Manav)" To: "Nobo Akiya (nobo)" , Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAE90UIAAFnEg Date: Thu, 20 Mar 2014 00:00:43 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B50DD@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20140319082501342601.778988ca@sniff.de> 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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/cWLj907aETIqrXfwfQFXI6NwD-Y Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 00:01:09 -0000 Adding on top of what Nobo has already said. New bfd.SessionType variables can be defined for S-BFD clients and reflecto= rs. The S-BFD draft will update the "D" bit based on the bfd.SessionType va= riable. This requires no other changes to 5880/5881. The S-BFD draft should= unequivocally define what the "D" bit means in the context of the S-BFD pa= ckets. It can still be called the "D" (demand) bit and will be redefined to someth= ing like below: Demand (D) S-BFD clients MUST always set the "D" bit which directs the S-BFD reflector= to reflect the S-BFD packets that it receives. The S-BFD reflectors should= discard all packets that come with the D bit clear. S-BFD clients MUST always ignore packets coming with the "D" bit set. Please note that we will always know the S-BFD clients/reflectors since the= y would use a new UDP port. I like this approach over the one that uses descriminator values simply bec= ause examining a bit to detect a loop is much easier to implement in hardwa= re. Looking at the descriminator values and then detecting a loop cannot be= easily done in HW. Since the approach using the "D" bit seems to be acceptable to quite a few = folks here, I would like to understand the reason, if any, for opposing thi= s. Cheers, Manav > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Wednesday, March 19, 2014 9:22 PM > To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > > we will see how the discussion goes although I personally do not > think the > > M and D bit can be compared. Seems other people didn't see D a good > fit > > (formally) either. Anyway, I'll have a look again at the "M" bit and > the > > multipoint draft. >=20 > You are right Marc, M and D bit alone is not a good comparison. > However, it's not just M bit that's updated in the multipoint draft. > Multipoint draft updates M bit, introduces new state variables > (bfd.SessionType) and updates RX procedures. >=20 > Take a look at following sections in the multipoint draft. > 4.4.1. New State Variable > 4.16.1. Reception of BFD Control Packets > 4.16.2. Demultiplexing BFD Control Packets >=20 > Since your_discrim in S-BFD (both directions) is never zero(0), > bfd.SessionType is derivable for all cases. And D bit check can be > added for new bfd.SessionType values defined for S-BFD (both > directions), as part of RX procedures. Not only this approach doesn't > require BFDv2, it also addresses the point raised by Greg (i.e. support > for non-IP based S-BFD). >=20 > -Nobo >=20 > > -----Original Message----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Wednesday, March 19, 2014 11:25 AM > > To: MALLIK MUDIGONDA (mmudigon) > > Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > > bfd@ietf.org > > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Hello Mallik, > > > > we will see how the discussion goes although I personally do not > think the > > M and D bit can be compared. Seems other people didn't see D a good > fit > > (formally) either. Anyway, I'll have a look again at the "M" bit and > the > > multipoint draft. > > > > > > > Regarding the discriminator usage for solving this, we do not want > to > > > put any specific restrictions on the way discriminators are used. > > > > what restriction? > > > > > That's the reason the thread stopped there. Can't think of any > > > particular use case where MyDisc is used to demux, but that's the > > > reason not to impose this restriction. > > > > Huh?! There is some misunderstanding here, so let me repeat the > > discriminator idea: > > > > (1) S-BFD initiator R1 sends a BFD packet to reflector R2 > > > > (2) Reflector R2 copies the my_discr from incoming packet into > your_discr > > for outgoing packet. > > > > (3) Reflector R2 copies one of his local discriminator values into > my_discr of > > the outgoing packet. This local discriminator is not a "reflector > > discriminator" of R2. > > > > (4) The S-BFD initiator R1 is doing normal BFD operations by looking > into the > > your_discr of the reflected packet to demux. > > > > Especially R1 is not using "my_discr" of the reflected packet to > demux. > > > > The point is: when someone is injecting an "endless loop" packet by > using > > the "reflector discriminator" of R1 as my_discr, the reflector > discriminator of > > R2 as your_discr and sends the packet to R2 then the steps above > result in a > > packet > > > > attacker -> R2 -> R1 -> R2 -> drop/punt > > > > So after maximum 2 reflections the loop is broken. > > > > > > Regards, Marc > > > > From nobody Wed Mar 19 17:50:30 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25B1A0851 for ; Wed, 19 Mar 2014 17:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqib_SUKAkIy for ; Wed, 19 Mar 2014 17:50:15 -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 A3A781A0835 for ; Wed, 19 Mar 2014 17:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6647; q=dns/txt; s=iport; t=1395276607; x=1396486207; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dvN7qCwx0Csrfo1lMiGgYp1/O+s+PCRgSzarywUiH30=; b=hrT80gJbVRw+PESSPWIurIznYzEIgEUkERfpD4zCrpXjJPy5B/zVWWFe xmcyRN/qbHkt2JYUTDsHzHKV4Z23jWIvyttxLTY5o5wyLDv2oL4YtF7fh XZfipRqbMMShQm+ApZhYyRzOU91Iw1WV2J2bPNvyI2CJ+xc5+qBbJYgVK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIM6KlOtJV2d/2dsb2JhbABagmUhgRLCTYEdFnSCJQEBAQMBJxM/BQcEAgEIEQQBAQsUCQcyFAkIAgQBDQUIh2kIAdAzF440MQcGgx6BFAEDqneDLYIr X-IronPort-AV: E=Sophos;i="4.97,690,1389744000"; d="scan'208";a="311559035" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 20 Mar 2014 00:50:05 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2K0o5GS019186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 00:50:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 19:50:05 -0500 From: "Nobo Akiya (nobo)" To: "Bhatia, Manav (Manav)" , "Marc Binderberger" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAE90UIAAFnEggAAgw9A= Date: Thu, 20 Mar 2014 00:50:04 +0000 Message-ID: References: <20140319082501342601.778988ca@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B50DD@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B50DD@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.240.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Bf53-Pg0nKvtJin-M7aRs67tfrM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 00:50:23 -0000 Agree with Manav. One nit and one clarification. > S-BFD clients MUST always set the "D" bit which directs the S-BFD reflect= or > to reflect the S-BFD packets that it receives. The S-BFD reflectors shoul= d > discard all packets that come with the D bit clear. s/The S-BFD reflectors should discard/The S-BFD reflectors MUST discard/ > Please note that we will always know the S-BFD clients/reflectors since t= hey > would use a new UDP port. If implementation shares the local discriminator pool between BFD and S-BFD= , then session object located with your_discrim in incoming packet will pro= vide the bfd.SessionType. In this implementation, non-IP based S-BFD can be= supported without new G-Ach code point for S-BFD. If implementation does n= ot share the local discriminator pool between BFD and S-BFD, then UDP port = is required to first figure out which table to lookup the session object, i= n which case will provide BFD or S-BFD answer. In this implementation, non-= IP based S-BFD will require separate G-Ach code point than BFD (but one new= G-Ach code point for S-BFD should be sufficient). We should probably assum= e that the latter is needed. -Nobo > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Wednesday, March 19, 2014 8:01 PM > To: Nobo Akiya (nobo); Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Adding on top of what Nobo has already said. >=20 > New bfd.SessionType variables can be defined for S-BFD clients and > reflectors. The S-BFD draft will update the "D" bit based on the > bfd.SessionType variable. This requires no other changes to 5880/5881. Th= e > S-BFD draft should unequivocally define what the "D" bit means in the > context of the S-BFD packets. >=20 > It can still be called the "D" (demand) bit and will be redefined to > something like below: >=20 > Demand (D) >=20 > S-BFD clients MUST always set the "D" bit which directs the S-BFD reflect= or > to reflect the S-BFD packets that it receives. The S-BFD reflectors shoul= d > discard all packets that come with the D bit clear. >=20 > S-BFD clients MUST always ignore packets coming with the "D" bit set. >=20 > Please note that we will always know the S-BFD clients/reflectors since t= hey > would use a new UDP port. >=20 > I like this approach over the one that uses descriminator values simply > because examining a bit to detect a loop is much easier to implement in > hardware. Looking at the descriminator values and then detecting a loop > cannot be easily done in HW. >=20 > Since the approach using the "D" bit seems to be acceptable to quite a fe= w > folks here, I would like to understand the reason, if any, for opposing t= his. >=20 > Cheers, Manav >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Wednesday, March 19, 2014 9:22 PM > > To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) > > Cc: rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > > we will see how the discussion goes although I personally do not > > think the > > > M and D bit can be compared. Seems other people didn't see D a good > > fit > > > (formally) either. Anyway, I'll have a look again at the "M" bit and > > the > > > multipoint draft. > > > > You are right Marc, M and D bit alone is not a good comparison. > > However, it's not just M bit that's updated in the multipoint draft. > > Multipoint draft updates M bit, introduces new state variables > > (bfd.SessionType) and updates RX procedures. > > > > Take a look at following sections in the multipoint draft. > > 4.4.1. New State Variable > > 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing BFD > > Control Packets > > > > Since your_discrim in S-BFD (both directions) is never zero(0), > > bfd.SessionType is derivable for all cases. And D bit check can be > > added for new bfd.SessionType values defined for S-BFD (both > > directions), as part of RX procedures. Not only this approach doesn't > > require BFDv2, it also addresses the point raised by Greg (i.e. > > support for non-IP based S-BFD). > > > > -Nobo > > > > > -----Original Message----- > > > From: Marc Binderberger [mailto:marc@sniff.de] > > > Sent: Wednesday, March 19, 2014 11:25 AM > > > To: MALLIK MUDIGONDA (mmudigon) > > > Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > > > bfd@ietf.org > > > Subject: Re: Loop Prevention in S-BFD > > > (draft-akiya-bfd-seamless-base) > > > > > > Hello Mallik, > > > > > > we will see how the discussion goes although I personally do not > > think the > > > M and D bit can be compared. Seems other people didn't see D a good > > fit > > > (formally) either. Anyway, I'll have a look again at the "M" bit and > > the > > > multipoint draft. > > > > > > > > > > Regarding the discriminator usage for solving this, we do not want > > to > > > > put any specific restrictions on the way discriminators are used. > > > > > > what restriction? > > > > > > > That's the reason the thread stopped there. Can't think of any > > > > particular use case where MyDisc is used to demux, but that's the > > > > reason not to impose this restriction. > > > > > > Huh?! There is some misunderstanding here, so let me repeat the > > > discriminator idea: > > > > > > (1) S-BFD initiator R1 sends a BFD packet to reflector R2 > > > > > > (2) Reflector R2 copies the my_discr from incoming packet into > > your_discr > > > for outgoing packet. > > > > > > (3) Reflector R2 copies one of his local discriminator values into > > my_discr of > > > the outgoing packet. This local discriminator is not a "reflector > > > discriminator" of R2. > > > > > > (4) The S-BFD initiator R1 is doing normal BFD operations by looking > > into the > > > your_discr of the reflected packet to demux. > > > > > > Especially R1 is not using "my_discr" of the reflected packet to > > demux. > > > > > > The point is: when someone is injecting an "endless loop" packet by > > using > > > the "reflector discriminator" of R1 as my_discr, the reflector > > discriminator of > > > R2 as your_discr and sends the packet to R2 then the steps above > > result in a > > > packet > > > > > > attacker -> R2 -> R1 -> R2 -> drop/punt > > > > > > So after maximum 2 reflections the loop is broken. > > > > > > > > > Regards, Marc > > > > > > From nobody Wed Mar 19 18:08:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218191A0870 for ; Wed, 19 Mar 2014 18:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-bO1mcYmyAP for ; Wed, 19 Mar 2014 18:08:03 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 360C11A086B for ; Wed, 19 Mar 2014 18:08:03 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 7224D2AA0F; Thu, 20 Mar 2014 01:07:52 +0000 (GMT) Date: Wed, 19 Mar 2014 18:07:58 -0700 From: Marc Binderberger To: Jeffrey Haas , "Bhatia, Manav (Manav)" Message-ID: <20140319180758624457.0dc0ae90@sniff.de> In-Reply-To: <20140319163739.GB30410@pfrc> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> Subject: Re: BFD v2? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gr9OR2UONkjS9nekATk2QS-F-j4 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 01:08:09 -0000 Hello Jeff, Manav et al., > I'm not convinced the s-bfd stuff has pushed us there quite yet. if I see the amount of discussions for a problem like the endless-loop then I think it is time to think forward, before we hit "there". Sure we will find a solution somehow for the loop problem within v1 - nobody wants to delay this work, including me. I'm just using this example as it highlights so nicely what I think is going wrong meanwhile. All we need is a fresh flag, without the "clever" reuse of existing fields or the clever word-twisting (or sometimes just bold statements) why a reuse is "okay". >> use case where we cant work with the existing fields at all A sharp line of "can't work" does not exist. It's always opinions. And if you have a new feature with customers asking for standardization then there will be always a way in v1, no matter how "bent". If the situation is so painful that everyone wants to give in to "v2" then it's too late. We would do a rush job for "v2" then where we should take (some) time. > The second half of that opinion is "send at wire rate". I understand this as an advice for BFD protocol design but don't see what this has to do with v1 vs. v2 (?). Regards, Marc On Wed, 19 Mar 2014 12:37:39 -0400, Jeffrey Haas wrote: > On Wed, Mar 19, 2014 at 04:46:40AM +0000, Bhatia, Manav (Manav) wrote: >> All I am saying is that we should not bump the version # till we have a >> use case where we cant work with the existing fields at all and the change >> required is so radical that upping the version # is the only recourse >> left. > > This largely reflects my opinion. The second half of that opinion is "send > at wire rate". > > In the life of BFD, we've successfully resisted and engineered our way > around the urge to extend it for various things to keep the core use cases > of the protocol. Once we can no longer do that, then it's time to look at > bumping the version. > > I'm not convinced the s-bfd stuff has pushed us there quite yet. > > -- Jeff > From nobody Wed Mar 19 20:42:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779E01A0805 for ; Wed, 19 Mar 2014 20:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwxB57hinsPP for ; Wed, 19 Mar 2014 20:42:40 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B74A61A0345 for ; Wed, 19 Mar 2014 20:42:40 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s2K3gUuY004826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Mar 2014 22:42:31 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s2K3gTUo024319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 23:42:29 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Mar 2014 23:42:29 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Thu, 20 Mar 2014 11:42:26 +0800 From: "Bhatia, Manav (Manav)" To: Marc Binderberger , Jeffrey Haas Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GV7fdJzIOcMUybjKXyT+YC8JropGoAgACcD9A= Date: Thu, 20 Mar 2014 03:42:25 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> In-Reply-To: <20140319180758624457.0dc0ae90@sniff.de> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IN3B4PVmuT2seqM_TlAaLRfj9uo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 03:42:42 -0000 Hi Marc, >=20 > If the situation is so painful that everyone wants to give in to "v2" > then it's too late. We would do a rush job for "v2" then where we > should > take (some) time. >=20 A painful situation is not the only time when we might want to move to v2. = We may also want to do it, if for example, we want to extend BFD for OAM. T= oday we only get a binary result from BFD. i.e., in the context of S-BFD, t= he client only knows whether it can reach the reflector/server or not. In c= ase it cant, the client has no idea of where the fault lies. Now, if the in= dustry wants BFD to be extended to help diagnose such issues (isolate the f= ault), then the changes to the protocol would be significant and this could= be a candidate for a version bump. Cheers, Manav From nobody Wed Mar 19 22:29:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166381A086F for ; Wed, 19 Mar 2014 22:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKbeVYlPrtz1 for ; Wed, 19 Mar 2014 22:29:12 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 791BA1A0826 for ; Wed, 19 Mar 2014 22:29:12 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-b8-532a7a4c1452 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 83.C0.12743.C4A7A235; Thu, 20 Mar 2014 06:19:08 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 01:29:01 -0400 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , "Marc Binderberger" , Jeffrey Haas Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GV/153Eg7Dzkumfev7qVNARprpbZQAgAArJ4D//9ansA== Date: Thu, 20 Mar 2014 05:29:00 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPoK5PlVawwfnFUhb7D75ltZhz7x6r xewr/5ktPv/ZxujA4tH6bC+rx5IlP5k8LvduZfVoXd3NEsASxWWTkpqTWZZapG+XwJXxa3cj a8FvnoqNExewNTAu4upi5OSQEDCR+Nw8gx3CFpO4cG89WxcjF4eQwBFGibbVj1khnOWMErsf HQGrYhMwknixsYcdJCEi0Mwo8e7AI2aQBLOApkTTic9gRcICIhJnnsxmArFFBEQlJjx9wwph O0ncnfWKBcRmEVCVmPdgMhuIzSvgK7F14iGo1W2sEr8OzQMr4hSIldi4ei5YMyPQfd9PrWGC WCYucevJfCaIuwUkluw5zwxhi0q8fPyPFcJWkvj4ez47RL2OxILdn9ggbG2JZQtfM0MsFpQ4 OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBMbUMQk23R2Me15aHmKU5mBR Euf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjfFXs/vrZDl7KgrMY3mp1XretunFm zaG1i4rOxny7o3vl0/1PE3y6Pj7WiriSt9vzd9+Zkqv1sz4kX3hseW0H+8I+gZdeyxexKl2p 9PvBI7tm+ct35bnNHPdP125NXJlSmffqiVDdshWCqnpsO4W+3o/M/8GpGRAU+G9hytNyN+VV VT3iPZ5hSizFGYmGWsxFxYkACKBfJ3cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/r74DXWKe4Qx6MTy1e1BfkZjOY5Q Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 05:29:14 -0000 Hi Manav, IP OAM, unlike for example Ethernet Service OAM, is very fragmented indeed.= If we compare IP OAM with Y.1731, then BFD is most close to ETH-CC. Fault = isolation would done through by traceroute and ETH-LT respectively. And the= comparison can be continued to Performance Measurement with OWAMP/TWAMP co= mparable to 1DM and DMM/DMR. As I think, there are couple of functions Y.17= 31 that yet unmatched by IP OAM. Hence my question Does "we want to extend = BFD for OAM" mean extending BFD to match Y.1731 functionality? IMO, this is= very interesting topic to discuss. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav = (Manav) Sent: Wednesday, March 19, 2014 8:42 PM To: Marc Binderberger; Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: RE: BFD v2? Hi Marc, >=20 > If the situation is so painful that everyone wants to give in to "v2" > then it's too late. We would do a rush job for "v2" then where we=20 > should take (some) time. >=20 A painful situation is not the only time when we might want to move to v2. = We may also want to do it, if for example, we want to extend BFD for OAM. T= oday we only get a binary result from BFD. i.e., in the context of S-BFD, t= he client only knows whether it can reach the reflector/server or not. In c= ase it cant, the client has no idea of where the fault lies. Now, if the in= dustry wants BFD to be extended to help diagnose such issues (isolate the f= ault), then the changes to the protocol would be significant and this could= be a candidate for a version bump. Cheers, Manav From nobody Wed Mar 19 22:37:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2467E1A0826 for ; Wed, 19 Mar 2014 22:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3Xbof49HL0C for ; Wed, 19 Mar 2014 22:37:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 22ADA1A07FE for ; Wed, 19 Mar 2014 22:37:02 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-42-532a7b8d5643 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 21.C2.11484.D8B7A235; Thu, 20 Mar 2014 06:24:29 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 01:36:52 -0400 From: Jeff Tantsura To: Gregory Mirsky Subject: Re: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GVoifcXJQV10iHssAKHyaWQprpbZQAgAArJ4CAAB3IAP//vyUe Date: Thu, 20 Mar 2014 05:36:52 +0000 Message-ID: <0BE7CE89-0B41-4616-819B-EF7B8BDD13E1@ericsson.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXRPrG5vtVawwZnDNhb7D75ltZhz7x6r xewr/5ktPv/ZxujA4tH6bC+rx5IlP5k8LvduZfVoXd3NEsASxWWTkpqTWZZapG+XwJUx4Vcf S8EOwYpP8zkaGJ/wdjFycEgImEg8mcHYxcgJZIpJXLi3ng3EFhI4wigx65tQFyMXkL2cUeLL sY1gRWwCBhL/vx1nAbFFgOzby5YzgxQxC6xhlFjw4DszSEJYQETi5aKzjBBFohITnr5hhbDd JDa9X8QEYrMIqErcOrOcFeQIXgF7ib5TiRDLTrBKbDjTxQ4S5xTwk9j9CKycEei476fWgNnM AuISt57MZ4I4WkBiyZ7zzBC2qMTLx/9YIWp0JBbs/sQGYWtLLFv4GqyGV0BQ4uTMJywTGEVn IRk1C0nLLCQts5C0LGBkWcXIUVqcWpabbmS4iREYMcck2Bx3MC74ZHmIUZqDRUmc98tb5yAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjFPMj5dv8j8kWrjrv2Dc3FXmyW/2z6qru3VP02H5 osyYw1IeLht+MM+4G8X9bIbVgifbd3Ad5ZP8mqms9e5Y7aXdL7sWZm3SK7yuIJG7nuex2OcJ ezfMrm1/s0TGiPFD4DJfk7evTjEbBVftvNOnZWlRbH2lN3GNV8ebKUqZjs8uqG5lE7/yv0iJ pTgj0VCLuag4EQCL8DHzZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XAoojEiZud84xYQZ-QL3UfXeEUg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 05:37:04 -0000 Hi, I fully agree with Greg here - perhaps we should take time and discuss what= is that we have been missing in the current incarnation of BFD and what ar= e the problems we'd want v2 to solve. Most vendors have implemented BFD in silicon, any significant changes, unle= ss absolutely critical would not justify amount of work and changes needed= to accommodate such thing. Regards, Jeff > On Mar 19, 2014, at 10:29 PM, "Gregory Mirsky" wrote: >=20 > Hi Manav, > IP OAM, unlike for example Ethernet Service OAM, is very fragmented indee= d. If we compare IP OAM with Y.1731, then BFD is most close to ETH-CC. Faul= t isolation would done through by traceroute and ETH-LT respectively. And t= he comparison can be continued to Performance Measurement with OWAMP/TWAMP = comparable to 1DM and DMM/DMR. As I think, there are couple of functions Y.= 1731 that yet unmatched by IP OAM. Hence my question Does "we want to exten= d BFD for OAM" mean extending BFD to match Y.1731 functionality? IMO, this = is very interesting topic to discuss. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Mana= v (Manav) > Sent: Wednesday, March 19, 2014 8:42 PM > To: Marc Binderberger; Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Marc, >=20 >>=20 >> If the situation is so painful that everyone wants to give in to "v2" >> then it's too late. We would do a rush job for "v2" then where we=20 >> should take (some) time. >>=20 >=20 > A painful situation is not the only time when we might want to move to v2= . We may also want to do it, if for example, we want to extend BFD for OAM.= Today we only get a binary result from BFD. i.e., in the context of S-BFD,= the client only knows whether it can reach the reflector/server or not. In= case it cant, the client has no idea of where the fault lies. Now, if the = industry wants BFD to be extended to help diagnose such issues (isolate the= fault), then the changes to the protocol would be significant and this cou= ld be a candidate for a version bump. >=20 > Cheers, Manav >=20 >=20 From nobody Wed Mar 19 23:37:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB161A04A7 for ; Wed, 19 Mar 2014 23:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZatIWi7nxFS for ; Wed, 19 Mar 2014 23:37:46 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1908C1A04C5 for ; Wed, 19 Mar 2014 23:37:45 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s2K6bY9j020398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2014 01:37:34 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s2K6bX3j017938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 02:37:34 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 20 Mar 2014 02:37:33 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Thu, 20 Mar 2014 14:37:30 +0800 From: "Bhatia, Manav (Manav)" To: Gregory Mirsky Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GV7fdJzIOcMUybjKXyT+YC8JropGoAgACcD9D//6zfAIAAlT0Q Date: Thu, 20 Mar 2014 06:37:30 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6Ku5Xtg86ZnZ2-1U41SHlLLJNWQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 06:37:48 -0000 Hi Greg, I had taken extending BFD for OAM only as an example of when we may potenti= ally need to go in for a version bump. > As I think, > there are couple of functions Y.1731 that yet unmatched by IP OAM. > Hence my question Does "we want to extend BFD for OAM" mean extending > BFD to match Y.1731 functionality? IMO, this is very interesting topic > to discuss. Don't we have most of what Y.1731 offers available for MPLS networks? Did y= ou mean the gaps in OAM for pure IP (non-MPLS) networks? Cheers, Manav > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 20, 2014 10:59 AM > To: Bhatia, Manav (Manav); Marc Binderberger; Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Manav, > IP OAM, unlike for example Ethernet Service OAM, is very fragmented > indeed. If we compare IP OAM with Y.1731, then BFD is most close to > ETH-CC. Fault isolation would done through by traceroute and ETH-LT > respectively. And the comparison can be continued to Performance > Measurement with OWAMP/TWAMP comparable to 1DM and DMM/DMR. As I think, > there are couple of functions Y.1731 that yet unmatched by IP OAM. > Hence my question Does "we want to extend BFD for OAM" mean extending > BFD to match Y.1731 functionality? IMO, this is very interesting topic > to discuss. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, > Manav (Manav) > Sent: Wednesday, March 19, 2014 8:42 PM > To: Marc Binderberger; Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Marc, >=20 > > > > If the situation is so painful that everyone wants to give in to "v2" > > then it's too late. We would do a rush job for "v2" then where we > > should take (some) time. > > >=20 > A painful situation is not the only time when we might want to move to > v2. We may also want to do it, if for example, we want to extend BFD > for OAM. Today we only get a binary result from BFD. i.e., in the > context of S-BFD, the client only knows whether it can reach the > reflector/server or not. In case it cant, the client has no idea of > where the fault lies. Now, if the industry wants BFD to be extended to > help diagnose such issues (isolate the fault), then the changes to the > protocol would be significant and this could be a candidate for a > version bump. >=20 > Cheers, Manav >=20 From nobody Wed Mar 19 23:46:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7F91A04C5 for ; Wed, 19 Mar 2014 23:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV6yKhejP__s for ; Wed, 19 Mar 2014 23:46:06 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 035C11A04A7 for ; Wed, 19 Mar 2014 23:46:04 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s2K6jrhW014291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2014 01:45:53 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s2K6jpaH011756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 02:45:53 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 20 Mar 2014 02:45:51 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Thu, 20 Mar 2014 14:44:45 +0800 From: "Bhatia, Manav (Manav)" To: Gregory Mirsky Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GV7fdJzIOcMUybjKXyT+YC8JropGoAgACcD9D//6zfAIAAlT0QgAAFWJA= Date: Thu, 20 Mar 2014 06:44:44 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.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 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2Flw8lYv4RBbSBzF16kOmwTyEJ0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 06:46:07 -0000 >=20 > Don't we have most of what Y.1731 offers available for MPLS networks? > Did you mean the gaps in OAM for pure IP (non-MPLS) networks? And gaps in OAM for segment routed networks.=20 Cheers, Manav From nobody Thu Mar 20 00:01:23 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2B11A04E8 for ; Thu, 20 Mar 2014 00:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX6Mx1Cl4vpZ for ; Thu, 20 Mar 2014 00:01:18 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 786551A034C for ; Thu, 20 Mar 2014 00:01:18 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-65-532a8fe2fd48 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DE.81.12743.2EF8A235; Thu, 20 Mar 2014 07:51:14 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 03:01:08 -0400 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GV/153Eg7Dzkumfev7qVNARprpbZQAgAArJ4D//9ansIAAWkQAgAACBgD//73cQA== Date: Thu, 20 Mar 2014 07:01:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXRPrO6jfq1gg2sXNS3m3LvHavH5zzZG ByaP1md7WT2WLPnJFMAUxWWTkpqTWZZapG+XwJXR9/YcW8E59op9M64yNzBOZeti5OSQEDCR WPW8hRnCFpO4cG89UJyLQ0jgCKPE5x1/WCGc5YwSx39PYwepYhMwknixsQfMFhGwlXi+eRcL iM0soCnRdOIzWFxYQETizJPZTBA1ohITnr5hhbDDJJbNvgK2jUVAVaKn8wPYFbwCvhIvb91m BLGFBD6wSWx7IglicwrESjyaeApsJiPQdd9PrWGC2CUucevJfCaIqwUkluw5D/WBqMTLx/9Y IWwliY+/57ND1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUV I0dpcWpZbrqRwSZGYJwck2DT3cG456XlIUZpDhYlcd4vb52DhATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTA6Hyn839r/PDnK8Qxjqvui3YLx+7+qlnru2O79k8PpT59I6lrO8ymWQTaHjnOp lCSWe+z+Uq2ox9F1TrRo52sR4zMb7llNF5mpEmv+f+buK9pdYWrJsw+7vltRGjJrp3XUJpvK UqHnjN5/p1wMUmZLW1/44+/FdcUJRays8/jeSC0r9/l/958SS3FGoqEWc1FxIgAjMtlrYQIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/pGlRaScQsBtXZvTThlnzkWtIpto Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 07:01:20 -0000 Hi Manav, right, MPLS OAM is much functionally closer to Y.1731 though there are some= missing functions among them experimental and vendor-specific might be of = interest for us. But I'll note that MPLS Performance Measurement RFC 6374 a= nd MPLS-TP profile RFC 6375 need metrics definitions at least. Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, consider= ing that MPLS dataplane may make MPLS OAM re-usable in SPRING. (That to be = seen after we finish SPRING OAM Requirements and gap analysis). Regards, Greg -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Wednesday, March 19, 2014 11:45 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: RE: BFD v2? >=20 > Don't we have most of what Y.1731 offers available for MPLS networks? > Did you mean the gaps in OAM for pure IP (non-MPLS) networks? And gaps in OAM for segment routed networks.=20 Cheers, Manav From nobody Thu Mar 20 00:18:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105CB1A05E5 for ; Thu, 20 Mar 2014 00:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQFPxVh4F1n6 for ; Thu, 20 Mar 2014 00:18:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B296C1A0069 for ; Thu, 20 Mar 2014 00:18:32 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s2K7ILhN006127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2014 02:18:21 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s2K7IILa023138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 03:18:20 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 20 Mar 2014 03:18:19 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Thu, 20 Mar 2014 15:17:36 +0800 From: "Bhatia, Manav (Manav)" To: Gregory Mirsky Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GV7fdJzIOcMUybjKXyT+YC8JropGoAgACcD9D//6zfAIAAlT0QgAAFWJD//38ogIAAhu9w Date: Thu, 20 Mar 2014 07:17:35 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/z8BwhL1yVKspouWKIujLRpp6zeY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 07:18:34 -0000 Hi Greg, Ideally the demand should come from the operators in case they need enhance= d IP OAM capabilities (loss measurement, an equivalent of a link trace, etc= ) for pure IP networks. Has anybody ever asked for this? I am aware of the = ECMP issue where the IP OAM does not follow the traffic. But besides that, = is there anything else that folks have been asking for? Cheers, Manav > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 20, 2014 12:31 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Manav, > right, MPLS OAM is much functionally closer to Y.1731 though there are > some missing functions among them experimental and vendor-specific > might be of interest for us. But I'll note that MPLS Performance > Measurement RFC 6374 and MPLS-TP profile RFC 6375 need metrics > definitions at least. > Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, > considering that MPLS dataplane may make MPLS OAM re-usable in SPRING. > (That to be seen after we finish SPRING OAM Requirements and gap > analysis). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Wednesday, March 19, 2014 11:45 PM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > > > > Don't we have most of what Y.1731 offers available for MPLS networks? > > Did you mean the gaps in OAM for pure IP (non-MPLS) networks? >=20 > And gaps in OAM for segment routed networks. >=20 > Cheers, Manav From nobody Thu Mar 20 02:30:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A7A1A03A7 for ; Thu, 20 Mar 2014 02:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0CfXx2nM_Yz for ; Thu, 20 Mar 2014 02:29:58 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E610C1A035B for ; Thu, 20 Mar 2014 02:29:57 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so369496wgh.28 for ; Thu, 20 Mar 2014 02:29:48 -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=CnLISCZ9VfLxkBSTIDB7dAYZ11G+Zj8HFgKou6KBRsI=; b=z1mgdazCHiNH9KVN3Zk1IjZQ8yrvqSthKOV8d7bt1JSrAaN1azKSCcel2qaiwfaCuz vJeo7F0l9KeD0/ICrnGv5MJwnF3zp9nyn5K854vNSDBV9j9RsqRfOENFZRgcsbMwtcPZ Qd73HfhuvWhrKLi3xtHkFlKYrljRKJaMNe2gf+/x7ptrKT7vX0NHakd2ljGJrBOg/Qhs 3kUCKzE09yWtxiZ2XjotvsrgM5mZsyqTBsLVSSX5ixA0s8Sbgm7pTkDlUyKDaaBrxP45 7JFi9p48tWRjdNCAcKS+nmWVeEroh4m8X7AP53n1i404QomOABs5UFFLqILUgrdR5gPU CX9A== X-Received: by 10.194.84.144 with SMTP id z16mr33258349wjy.23.1395307788559; Thu, 20 Mar 2014 02:29:48 -0700 (PDT) Received: from [10.1.2.188] (a65.fluent.fr. [195.68.67.65]) by mx.google.com with ESMTPSA id pm2sm59021865wic.0.2014.03.20.02.29.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 02:29:46 -0700 (PDT) Subject: Re: BFD v2? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Sam K. Aldrin" In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Thu, 20 Mar 2014 02:29:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent .com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/71sS4XJxb8mx6wpEHUy2SvrM310 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 09:29:59 -0000 I would like to see requirements coming in from carriers as well. We might be over engineering, if there is no real need for doing so. There are different mechanisms, standard/proprietary for IP. Rather than revising BFD to increase the scope to making it heavy = weight, one needs to have real justification for 'why BFD?'. cheers -sam On Mar 20, 2014, at 12:17 AM, Bhatia, Manav (Manav) wrote: > Hi Greg, >=20 > Ideally the demand should come from the operators in case they need = enhanced IP OAM capabilities (loss measurement, an equivalent of a link = trace, etc) for pure IP networks. Has anybody ever asked for this? I am = aware of the ECMP issue where the IP OAM does not follow the traffic. = But besides that, is there anything else that folks have been asking = for? >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> Sent: Thursday, March 20, 2014 12:31 PM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: RE: BFD v2? >>=20 >> Hi Manav, >> right, MPLS OAM is much functionally closer to Y.1731 though there = are >> some missing functions among them experimental and vendor-specific >> might be of interest for us. But I'll note that MPLS Performance >> Measurement RFC 6374 and MPLS-TP profile RFC 6375 need metrics >> definitions at least. >> Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, >> considering that MPLS dataplane may make MPLS OAM re-usable in = SPRING. >> (That to be seen after we finish SPRING OAM Requirements and gap >> analysis). >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] >> Sent: Wednesday, March 19, 2014 11:45 PM >> To: Gregory Mirsky >> Cc: rtg-bfd@ietf.org >> Subject: RE: BFD v2? >>=20 >>>=20 >>> Don't we have most of what Y.1731 offers available for MPLS = networks? >>> Did you mean the gaps in OAM for pure IP (non-MPLS) networks? >>=20 >> And gaps in OAM for segment routed networks. >>=20 >> Cheers, Manav >=20 From nobody Thu Mar 20 04:01:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2421A06CB for ; Thu, 20 Mar 2014 04:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_NexqUvvIjL for ; Thu, 20 Mar 2014 04:01:43 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 219701A06C1 for ; Thu, 20 Mar 2014 04:01:42 -0700 (PDT) Received: from mail146-co9-R.bigfish.com (10.236.132.242) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.22; Thu, 20 Mar 2014 11:01:34 +0000 Received: from mail146-co9 (localhost [127.0.0.1]) by mail146-co9-R.bigfish.com (Postfix) with ESMTP id 01EB95E0083; Thu, 20 Mar 2014 11:01:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I146fI542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh2668h9a9j1155h) Received-SPF: pass (mail146-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=santoshpk@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(199002)(189002)(377454003)(52314003)(13464003)(66066001)(87266001)(80022001)(33646001)(74662001)(20776003)(85306002)(81342001)(65816001)(19580395003)(19580405001)(83322001)(81542001)(59766001)(2656002)(87936001)(76796001)(47446002)(74706001)(63696002)(92566001)(77982001)(31966008)(74316001)(56776001)(85852003)(90146001)(83072002)(79102001)(74876001)(93136001)(74502001)(56816005)(81816001)(97336001)(81686001)(46102001)(95666003)(76576001)(54316002)(97186001)(80976001)(69226001)(47976001)(50986001)(47736001)(53806001)(54356001)(51856001)(76482001)(4396001)(94316002)(49866001)(95416001)(86362001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:E6DCC614.9FFD95E1.73C171BB.8AF4DDF9.20591; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail146-co9 (localhost.localdomain [127.0.0.1]) by mail146-co9 (MessageSwitch) id 1395313292622039_15810; Thu, 20 Mar 2014 11:01:32 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.248]) by mail146-co9.bigfish.com (Postfix) with ESMTP id 9157AC80047; Thu, 20 Mar 2014 11:01:32 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 20 Mar 2014 11:01:27 +0000 Received: from BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 20 Mar 2014 11:01:26 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 20 Mar 2014 11:01:25 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.0898.005; Thu, 20 Mar 2014 11:01:24 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Bhatia, Manav (Manav)" , Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAEGvwCAAQylgIAAnxaAgALHwACAAAMxgIAAA9AAgAATlACAAAK7gIAAAjcAgAAC5ICAAAXLgIAAITAAgAWCtACAAAXCgIAAagwAgAGnmYCAAAMGAIAA7NmAgABodYCAAAeegIAAiHiAgAANygCAAKpGsA== Date: Thu, 20 Mar 2014 11:01:24 +0000 Message-ID: References: <20140319082501342601.778988ca@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B50DD@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: [116.197.184.16] x-forefront-prvs: 01565FED4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/35f3SFGHXwt91xO_6g-RVayUUCo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 11:01:46 -0000 Nobo, I am confused with your statement below. Can you please clarify? > If implementation shares the local discriminator pool between BFD and S-B= FD, > then session object located with your_discrim in incoming packet will pro= vide > the bfd.SessionType. If pool is shared then how can your_disc help to get the sessionType? Did y= ou mean not share pool between BFD and S-BFD?=20 Thanks Santosh P K > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Thursday, March 20, 2014 6:20 AM > To: Bhatia, Manav (Manav); Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Agree with Manav. >=20 > One nit and one clarification. >=20 > > S-BFD clients MUST always set the "D" bit which directs the S-BFD > > reflector to reflect the S-BFD packets that it receives. The S-BFD > > reflectors should discard all packets that come with the D bit clear. >=20 > s/The S-BFD reflectors should discard/The S-BFD reflectors MUST discard/ >=20 > > Please note that we will always know the S-BFD clients/reflectors > > since they would use a new UDP port. >=20 > If implementation shares the local discriminator pool between BFD and S-B= FD, > then session object located with your_discrim in incoming packet will pro= vide > the bfd.SessionType. In this implementation, non-IP based S-BFD can be > supported without new G-Ach code point for S-BFD. If implementation does = not > share the local discriminator pool between BFD and S-BFD, then UDP port i= s > required to first figure out which table to lookup the session object, in= which > case will provide BFD or S-BFD answer. In this implementation, non-IP bas= ed S- > BFD will require separate G-Ach code point than BFD (but one new G-Ach co= de > point for S-BFD should be sufficient). We should probably assume that the= latter > is needed. >=20 > -Nobo >=20 > > -----Original Message----- > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > Sent: Wednesday, March 19, 2014 8:01 PM > > To: Nobo Akiya (nobo); Marc Binderberger > > Cc: rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Adding on top of what Nobo has already said. > > > > New bfd.SessionType variables can be defined for S-BFD clients and > > reflectors. The S-BFD draft will update the "D" bit based on the > > bfd.SessionType variable. This requires no other changes to 5880/5881. > > The S-BFD draft should unequivocally define what the "D" bit means in > > the context of the S-BFD packets. > > > > It can still be called the "D" (demand) bit and will be redefined to > > something like below: > > > > Demand (D) > > > > S-BFD clients MUST always set the "D" bit which directs the S-BFD > > reflector to reflect the S-BFD packets that it receives. The S-BFD > > reflectors should discard all packets that come with the D bit clear. > > > > S-BFD clients MUST always ignore packets coming with the "D" bit set. > > > > Please note that we will always know the S-BFD clients/reflectors > > since they would use a new UDP port. > > > > I like this approach over the one that uses descriminator values > > simply because examining a bit to detect a loop is much easier to > > implement in hardware. Looking at the descriminator values and then > > detecting a loop cannot be easily done in HW. > > > > Since the approach using the "D" bit seems to be acceptable to quite a > > few folks here, I would like to understand the reason, if any, for oppo= sing this. > > > > Cheers, Manav > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > > Akiya > > > (nobo) > > > Sent: Wednesday, March 19, 2014 9:22 PM > > > To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: Loop Prevention in S-BFD > > > (draft-akiya-bfd-seamless-base) > > > > > > > we will see how the discussion goes although I personally do not > > > think the > > > > M and D bit can be compared. Seems other people didn't see D a > > > > good > > > fit > > > > (formally) either. Anyway, I'll have a look again at the "M" bit > > > > and > > > the > > > > multipoint draft. > > > > > > You are right Marc, M and D bit alone is not a good comparison. > > > However, it's not just M bit that's updated in the multipoint draft. > > > Multipoint draft updates M bit, introduces new state variables > > > (bfd.SessionType) and updates RX procedures. > > > > > > Take a look at following sections in the multipoint draft. > > > 4.4.1. New State Variable > > > 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing BFD > > > Control Packets > > > > > > Since your_discrim in S-BFD (both directions) is never zero(0), > > > bfd.SessionType is derivable for all cases. And D bit check can be > > > added for new bfd.SessionType values defined for S-BFD (both > > > directions), as part of RX procedures. Not only this approach > > > doesn't require BFDv2, it also addresses the point raised by Greg (i.= e. > > > support for non-IP based S-BFD). > > > > > > -Nobo > > > > > > > -----Original Message----- > > > > From: Marc Binderberger [mailto:marc@sniff.de] > > > > Sent: Wednesday, March 19, 2014 11:25 AM > > > > To: MALLIK MUDIGONDA (mmudigon) > > > > Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > > > > bfd@ietf.org > > > > Subject: Re: Loop Prevention in S-BFD > > > > (draft-akiya-bfd-seamless-base) > > > > > > > > Hello Mallik, > > > > > > > > we will see how the discussion goes although I personally do not > > > think the > > > > M and D bit can be compared. Seems other people didn't see D a > > > > good > > > fit > > > > (formally) either. Anyway, I'll have a look again at the "M" bit > > > > and > > > the > > > > multipoint draft. > > > > > > > > > > > > > Regarding the discriminator usage for solving this, we do not > > > > > want > > > to > > > > > put any specific restrictions on the way discriminators are used. > > > > > > > > what restriction? > > > > > > > > > That's the reason the thread stopped there. Can't think of any > > > > > particular use case where MyDisc is used to demux, but that's > > > > > the reason not to impose this restriction. > > > > > > > > Huh?! There is some misunderstanding here, so let me repeat the > > > > discriminator idea: > > > > > > > > (1) S-BFD initiator R1 sends a BFD packet to reflector R2 > > > > > > > > (2) Reflector R2 copies the my_discr from incoming packet into > > > your_discr > > > > for outgoing packet. > > > > > > > > (3) Reflector R2 copies one of his local discriminator values into > > > my_discr of > > > > the outgoing packet. This local discriminator is not a "reflector > > > > discriminator" of R2. > > > > > > > > (4) The S-BFD initiator R1 is doing normal BFD operations by > > > > looking > > > into the > > > > your_discr of the reflected packet to demux. > > > > > > > > Especially R1 is not using "my_discr" of the reflected packet to > > > demux. > > > > > > > > The point is: when someone is injecting an "endless loop" packet > > > > by > > > using > > > > the "reflector discriminator" of R1 as my_discr, the reflector > > > discriminator of > > > > R2 as your_discr and sends the packet to R2 then the steps above > > > result in a > > > > packet > > > > > > > > attacker -> R2 -> R1 -> R2 -> drop/punt > > > > > > > > So after maximum 2 reflections the loop is broken. > > > > > > > > > > > > Regards, Marc > > > > > > > > >=20 >=20 From nobody Thu Mar 20 04:41:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6C01A071B for ; Thu, 20 Mar 2014 04:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZvk8JOzS6wm for ; Thu, 20 Mar 2014 04:41:05 -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 B359A1A06CF for ; Thu, 20 Mar 2014 04:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9341; q=dns/txt; s=iport; t=1395315656; x=1396525256; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HsdeKshB+Gz6CSRGwUF1PWWjeb2zWwiEJ4J8uRYiYnE=; b=ZE47C4Hzd3NA88FNurgJNdLdW/Jfk6wyudsKf5eWPrdc+d6Z92N+wwO0 VK1UWnXUAGbvpSegTzX/l30YY1H3l9VIzWGFWsv1V/KijmHp0DE/hId9W aQh0MgNAuk3o/Ky+6WnZA5eMeVGp1ZTsxbTd70ZRCYHuEsMjP+2On4YQT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFABXTKlOtJXG//2dsb2JhbABagmUhgRLCUIEeFnSCJQEBAQMBJxM/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiHaQgB0CoXjjQxBwaDHoEUAQOqd4Mtgis X-IronPort-AV: E=Sophos;i="4.97,694,1389744000"; d="scan'208";a="311438204" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 20 Mar 2014 11:40:55 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2KBetKR019732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 11:40:55 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 06:40:54 -0500 From: "Nobo Akiya (nobo)" To: Santosh P K , "Bhatia, Manav (Manav)" , Marc Binderberger Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAE90UIAAFnEggAAgw9CAAMIGAIAASljQ Date: Thu, 20 Mar 2014 11:40:54 +0000 Message-ID: References: <20140319082501342601.778988ca@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B50DD@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: [10.82.240.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OEgKnkp33K7I_EYFlG2kPx3YcE4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 11:41:07 -0000 Hi Santosh, > > If implementation shares the local discriminator pool between BFD and > > S-BFD, then session object located with your_discrim in incoming > > packet will provide the bfd.SessionType. >=20 > If pool is shared then how can your_disc help to get the sessionType? Did > you mean not share pool between BFD and S-BFD? If we mimic the logic from multipoint draft, it would be something like thi= s. If the Your Discriminator field is nonzero Select a session based on the value of Your Discriminator. If no session is found, the packet MUST be discarded. If bfd.SessionType is SBFDInitiator If Demand (D) bit is set, the packet MUST be discarded. Else if bfd.sessionType is SBFDReflector If Demand (D) bit is clear, the packet MUST be discarded. Else (non S-BFD) ...=20 -Nobo > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Thursday, March 20, 2014 7:01 AM > To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Nobo, > I am confused with your statement below. Can you please clarify? >=20 >=20 > > If implementation shares the local discriminator pool between BFD and > > S-BFD, then session object located with your_discrim in incoming > > packet will provide the bfd.SessionType. >=20 > If pool is shared then how can your_disc help to get the sessionType? Did > you mean not share pool between BFD and S-BFD? >=20 >=20 > Thanks > Santosh P K >=20 >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Thursday, March 20, 2014 6:20 AM > > To: Bhatia, Manav (Manav); Marc Binderberger > > Cc: rtg-bfd@ietf.org > > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > > > > Agree with Manav. > > > > One nit and one clarification. > > > > > S-BFD clients MUST always set the "D" bit which directs the S-BFD > > > reflector to reflect the S-BFD packets that it receives. The S-BFD > > > reflectors should discard all packets that come with the D bit clear. > > > > s/The S-BFD reflectors should discard/The S-BFD reflectors MUST > > discard/ > > > > > Please note that we will always know the S-BFD clients/reflectors > > > since they would use a new UDP port. > > > > If implementation shares the local discriminator pool between BFD and > > S-BFD, then session object located with your_discrim in incoming > > packet will provide the bfd.SessionType. In this implementation, > > non-IP based S-BFD can be supported without new G-Ach code point for > > S-BFD. If implementation does not share the local discriminator pool > > between BFD and S-BFD, then UDP port is required to first figure out > > which table to lookup the session object, in which case will provide > > BFD or S-BFD answer. In this implementation, non-IP based S- BFD will > > require separate G-Ach code point than BFD (but one new G-Ach code > > point for S-BFD should be sufficient). We should probably assume that t= he > latter is needed. > > > > -Nobo > > > > > -----Original Message----- > > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > > Sent: Wednesday, March 19, 2014 8:01 PM > > > To: Nobo Akiya (nobo); Marc Binderberger > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: Loop Prevention in S-BFD > > > (draft-akiya-bfd-seamless-base) > > > > > > Adding on top of what Nobo has already said. > > > > > > New bfd.SessionType variables can be defined for S-BFD clients and > > > reflectors. The S-BFD draft will update the "D" bit based on the > > > bfd.SessionType variable. This requires no other changes to 5880/5881= . > > > The S-BFD draft should unequivocally define what the "D" bit means > > > in the context of the S-BFD packets. > > > > > > It can still be called the "D" (demand) bit and will be redefined to > > > something like below: > > > > > > Demand (D) > > > > > > S-BFD clients MUST always set the "D" bit which directs the S-BFD > > > reflector to reflect the S-BFD packets that it receives. The S-BFD > > > reflectors should discard all packets that come with the D bit clear. > > > > > > S-BFD clients MUST always ignore packets coming with the "D" bit set. > > > > > > Please note that we will always know the S-BFD clients/reflectors > > > since they would use a new UDP port. > > > > > > I like this approach over the one that uses descriminator values > > > simply because examining a bit to detect a loop is much easier to > > > implement in hardware. Looking at the descriminator values and then > > > detecting a loop cannot be easily done in HW. > > > > > > Since the approach using the "D" bit seems to be acceptable to quite > > > a few folks here, I would like to understand the reason, if any, for > opposing this. > > > > > > Cheers, Manav > > > > > > > -----Original Message----- > > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > > > Akiya > > > > (nobo) > > > > Sent: Wednesday, March 19, 2014 9:22 PM > > > > To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) > > > > Cc: rtg-bfd@ietf.org > > > > Subject: RE: Loop Prevention in S-BFD > > > > (draft-akiya-bfd-seamless-base) > > > > > > > > > we will see how the discussion goes although I personally do not > > > > think the > > > > > M and D bit can be compared. Seems other people didn't see D a > > > > > good > > > > fit > > > > > (formally) either. Anyway, I'll have a look again at the "M" bit > > > > > and > > > > the > > > > > multipoint draft. > > > > > > > > You are right Marc, M and D bit alone is not a good comparison. > > > > However, it's not just M bit that's updated in the multipoint draft= . > > > > Multipoint draft updates M bit, introduces new state variables > > > > (bfd.SessionType) and updates RX procedures. > > > > > > > > Take a look at following sections in the multipoint draft. > > > > 4.4.1. New State Variable > > > > 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing > > > > BFD Control Packets > > > > > > > > Since your_discrim in S-BFD (both directions) is never zero(0), > > > > bfd.SessionType is derivable for all cases. And D bit check can be > > > > added for new bfd.SessionType values defined for S-BFD (both > > > > directions), as part of RX procedures. Not only this approach > > > > doesn't require BFDv2, it also addresses the point raised by Greg (= i.e. > > > > support for non-IP based S-BFD). > > > > > > > > -Nobo > > > > > > > > > -----Original Message----- > > > > > From: Marc Binderberger [mailto:marc@sniff.de] > > > > > Sent: Wednesday, March 19, 2014 11:25 AM > > > > > To: MALLIK MUDIGONDA (mmudigon) > > > > > Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > > > > > bfd@ietf.org > > > > > Subject: Re: Loop Prevention in S-BFD > > > > > (draft-akiya-bfd-seamless-base) > > > > > > > > > > Hello Mallik, > > > > > > > > > > we will see how the discussion goes although I personally do not > > > > think the > > > > > M and D bit can be compared. Seems other people didn't see D a > > > > > good > > > > fit > > > > > (formally) either. Anyway, I'll have a look again at the "M" bit > > > > > and > > > > the > > > > > multipoint draft. > > > > > > > > > > > > > > > > Regarding the discriminator usage for solving this, we do not > > > > > > want > > > > to > > > > > > put any specific restrictions on the way discriminators are use= d. > > > > > > > > > > what restriction? > > > > > > > > > > > That's the reason the thread stopped there. Can't think of any > > > > > > particular use case where MyDisc is used to demux, but that's > > > > > > the reason not to impose this restriction. > > > > > > > > > > Huh?! There is some misunderstanding here, so let me repeat the > > > > > discriminator idea: > > > > > > > > > > (1) S-BFD initiator R1 sends a BFD packet to reflector R2 > > > > > > > > > > (2) Reflector R2 copies the my_discr from incoming packet into > > > > your_discr > > > > > for outgoing packet. > > > > > > > > > > (3) Reflector R2 copies one of his local discriminator values > > > > > into > > > > my_discr of > > > > > the outgoing packet. This local discriminator is not a > > > > > "reflector discriminator" of R2. > > > > > > > > > > (4) The S-BFD initiator R1 is doing normal BFD operations by > > > > > looking > > > > into the > > > > > your_discr of the reflected packet to demux. > > > > > > > > > > Especially R1 is not using "my_discr" of the reflected packet to > > > > demux. > > > > > > > > > > The point is: when someone is injecting an "endless loop" packet > > > > > by > > > > using > > > > > the "reflector discriminator" of R1 as my_discr, the reflector > > > > discriminator of > > > > > R2 as your_discr and sends the packet to R2 then the steps above > > > > result in a > > > > > packet > > > > > > > > > > attacker -> R2 -> R1 -> R2 -> drop/punt > > > > > > > > > > So after maximum 2 reflections the loop is broken. > > > > > > > > > > > > > > > Regards, Marc > > > > > > > > > > > > > > >=20 From nobody Thu Mar 20 06:03:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2231A0740 for ; Thu, 20 Mar 2014 06:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF0NT8oaqsfT for ; Thu, 20 Mar 2014 06:03:04 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8F1A06CF for ; Thu, 20 Mar 2014 06:03:04 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s2KD14A7011618; Thu, 20 Mar 2014 09:02:53 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1jqxt8rcuh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Mar 2014 09:02:53 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 20 Mar 2014 09:02:52 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 20 Mar 2014 09:02:50 -0400 From: "Shah, Himanshu" To: "Sam K. Aldrin" , "Bhatia, Manav (Manav)" Date: Thu, 20 Mar 2014 09:02:48 -0400 Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: Ac9EHvRp+Z5vA1wTQjyUJ4tqRDDjWQAHTP1g Message-ID: <40746B2300A8FC4AB04EE722A593182B6DB84952@ONWVEXCHMB04.ciena.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent .com> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20576.006 X-TM-AS-Result: No--20.919800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-20_03:2014-03-20,2014-03-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403200061 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Goft9lOqSllZrkDBKk8mRVN5nak Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 13:03:07 -0000 Agree with Sam and Manav - lets have operator's input.=20 V2 may have h/w implications as well, so lets tread carefully?? /himanshu -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sam K. Aldrin Sent: Thursday, March 20, 2014 5:30 AM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: BFD v2? I would like to see requirements coming in from carriers as well. We might be over engineering, if there is no real need for doing so. There are different mechanisms, standard/proprietary for IP. Rather than revising BFD to increase the scope to making it heavy weight, o= ne needs to have real justification for 'why BFD?'. cheers -sam On Mar 20, 2014, at 12:17 AM, Bhatia, Manav (Manav) wrote: > Hi Greg, >=20 > Ideally the demand should come from the operators in case they need enhan= ced IP OAM capabilities (loss measurement, an equivalent of a link trace, e= tc) for pure IP networks. Has anybody ever asked for this? I am aware of th= e ECMP issue where the IP OAM does not follow the traffic. But besides that= , is there anything else that folks have been asking for? >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> Sent: Thursday, March 20, 2014 12:31 PM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: RE: BFD v2? >>=20 >> Hi Manav, >> right, MPLS OAM is much functionally closer to Y.1731 though there=20 >> are some missing functions among them experimental and=20 >> vendor-specific might be of interest for us. But I'll note that MPLS=20 >> Performance Measurement RFC 6374 and MPLS-TP profile RFC 6375 need=20 >> metrics definitions at least. >> Yes, I did mean non-MPLS IP. Segment Routed networks - no so much,=20 >> considering that MPLS dataplane may make MPLS OAM re-usable in SPRING. >> (That to be seen after we finish SPRING OAM Requirements and gap=20 >> analysis). >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] >> Sent: Wednesday, March 19, 2014 11:45 PM >> To: Gregory Mirsky >> Cc: rtg-bfd@ietf.org >> Subject: RE: BFD v2? >>=20 >>>=20 >>> Don't we have most of what Y.1731 offers available for MPLS networks? >>> Did you mean the gaps in OAM for pure IP (non-MPLS) networks? >>=20 >> And gaps in OAM for segment routed networks. >>=20 >> Cheers, Manav >=20 From nobody Thu Mar 20 08:24:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762501A08DA for ; Thu, 20 Mar 2014 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT-JMg8O0nIe for ; Thu, 20 Mar 2014 08:24:23 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 98D531A08DF for ; Thu, 20 Mar 2014 08:24:23 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-06-532b05368e0a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7B.D0.11484.6350B235; Thu, 20 Mar 2014 16:11:50 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 11:24:13 -0400 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GV/153Eg7Dzkumfev7qVNARprpbZQAgAArJ4D//9ansIAAWkQAgAACBgD//73cQIAAS1GAgABC3gA= Date: Thu, 20 Mar 2014 15:24:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B788D8A@eusaamb103.ericsson.se> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXRPuK4Zq3awwfT/chZz7t1jtfj8Zxuj A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MroaA0suC9S8XXyerYGxgcCXYycHBICJhLL tjxng7DFJC7cWw9kc3EICRxhlLi97TgjhLOcUeLn5/3MIFVsAkYSLzb2sIPYIgK2Es8372IB sZkFNCWaTnwGiwsLiEiceTKbCaJGVGLC0zesEHaSxO45V8BqWARUJRZe6QLr5RXwlejs/gS1 uZ1D4snJnWDLOAViJW4+PA9WxAh03vdTa5gglolL3HoynwnibAGJJXvOM0PYohIvH/9jhbAV Jfb1T2eHqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRo7S 4tSy3HQjw02MwDg5JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamA0CuzpOz3pfPIavSk+bF9tmzUm17nasro7acjun2Gt89nG8YFkySK+lZmzfLyqN3ws s0sxlIs3Wed44tb9gI6eZRt3l085wJpUKnU9dv6lQ7P+xZQy7udOEAidGLMqT95qG2PC4fOv Fk1Y19KU8eH/aobyP4vMOCQ5/DluedqYH9hsK3Bt4n8lluKMREMt5qLiRAAUrDLMYQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/DKHEb0T-L2FIFnbyNa0CbmiR-ek Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 15:24:26 -0000 Hi Manav, regarding IP Performance Measurement I can point to IPPM WG. Everything tha= t is related to measurement of performance of IP transports (UDP, TCP) and = IP-based applications is in scope of IPPM WG. As mentioned earlier, OWAMP a= nd TWAMP protocols support measurement of delay and delay variation both on= e-way and two-way metrics. As for link trace, I think that traceroute does = that already. The problem of "in-band" OAM does exist and Nobo and I recently talked abou= t it on this thread. I agree with Nobo that if an operator needs in-band OA= M over ECMP then hashing must exclude Destination and Source UDP ports. What's left? That is good question, particularly for operators that plan to= use Segment Routing with IPv6 dataplane. Regards, Greg -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Thursday, March 20, 2014 12:18 AM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: RE: BFD v2? Hi Greg, Ideally the demand should come from the operators in case they need enhance= d IP OAM capabilities (loss measurement, an equivalent of a link trace, etc= ) for pure IP networks. Has anybody ever asked for this? I am aware of the = ECMP issue where the IP OAM does not follow the traffic. But besides that, = is there anything else that folks have been asking for? Cheers, Manav > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 20, 2014 12:31 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Manav, > right, MPLS OAM is much functionally closer to Y.1731 though there are=20 > some missing functions among them experimental and vendor-specific=20 > might be of interest for us. But I'll note that MPLS Performance=20 > Measurement RFC 6374 and MPLS-TP profile RFC 6375 need metrics=20 > definitions at least. > Yes, I did mean non-MPLS IP. Segment Routed networks - no so much,=20 > considering that MPLS dataplane may make MPLS OAM re-usable in SPRING. > (That to be seen after we finish SPRING OAM Requirements and gap=20 > analysis). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Wednesday, March 19, 2014 11:45 PM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > > > > Don't we have most of what Y.1731 offers available for MPLS networks? > > Did you mean the gaps in OAM for pure IP (non-MPLS) networks? >=20 > And gaps in OAM for segment routed networks. >=20 > Cheers, Manav From nobody Fri Mar 21 11:40:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230AB1A09FF for ; Fri, 21 Mar 2014 11:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm2h8_OXdjZw for ; Fri, 21 Mar 2014 11:40:38 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2CF1A09FD for ; Fri, 21 Mar 2014 11:40:37 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 264D82AA0F; Fri, 21 Mar 2014 18:40:24 +0000 (GMT) Date: Fri, 21 Mar 2014 11:40:23 -0700 From: Marc Binderberger To: "Shah, Himanshu" Message-ID: <20140321114023944262.7de61dd6@sniff.de> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B6DB84952@ONWVEXCHMB04.ciena.com> References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent .com> <40746B2300A8FC4AB04EE722A593182B6DB84952@ONWVEXCHMB04.ciena.com> Subject: RE: BFD v2? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2nQtdKQQ3-xhEC92Fl-UbWEKKCw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 Mar 2014 18:40:41 -0000 Hello Shah et al., agree we should do changes for good reasons. Operator input is vital - but is not everything. Actually my experience is that operators have an idea about the bigger picture, potentially detailed requirements. But the rest is "whatever you implement. But make it interoperable" :-) So there may be operator-driven reasons. There may be reasons from the vendor side. The hardware aspect is interesting. Obviously it's a barrier for change, higher than on the software side (if we talk about fixed ASICs). But staying with v1 also faces hardware implementation difficulties as we make the rules for the few flags more complex over time. The feedback from Mallik about P/F flags is a good example where it sometimes hurts with v1. The feedback from several people, showing sympathy to think the different direction of "v2" should be taken as an early sign to think about this topic. Nobody likes the trouble of change. And I'm not saying we are doomed end of this year if you don't agree with me ;-) The change aspect may be overestimated, btw.. Technology is changing fast and "needs the next I/O card, ASIC, NP" is not so uncommon, the writeoff time of 3-5 years for IP equipment. Regards, Marc On Thu, 20 Mar 2014 09:02:48 -0400, Shah, Himanshu wrote: > Agree with Sam and Manav - lets have operator's input. > V2 may have h/w implications as well, so lets tread carefully?? > > /himanshu > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sam K. Aldrin > Sent: Thursday, March 20, 2014 5:30 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD v2? > > I would like to see requirements coming in from carriers as well. > We might be over engineering, if there is no real need for doing so. > > There are different mechanisms, standard/proprietary for IP. > Rather than revising BFD to increase the scope to making it heavy > weight, one needs to have real justification for 'why BFD?'. > > cheers > -sam > On Mar 20, 2014, at 12:17 AM, Bhatia, Manav (Manav) wrote: > >> Hi Greg, >> >> Ideally the demand should come from the operators in case they need >> enhanced IP OAM capabilities (loss measurement, an equivalent of a >> link trace, etc) for pure IP networks. Has anybody ever asked for >> this? I am aware of the ECMP issue where the IP OAM does not follow >> the traffic. But besides that, is there anything else that folks >> have been asking for? >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>> Sent: Thursday, March 20, 2014 12:31 PM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: BFD v2? >>> >>> Hi Manav, >>> right, MPLS OAM is much functionally closer to Y.1731 though there >>> are some missing functions among them experimental and >>> vendor-specific might be of interest for us. But I'll note that MPLS >>> Performance Measurement RFC 6374 and MPLS-TP profile RFC 6375 need >>> metrics definitions at least. >>> Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, >>> considering that MPLS dataplane may make MPLS OAM re-usable in SPRING. >>> (That to be seen after we finish SPRING OAM Requirements and gap >>> analysis). >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] >>> Sent: Wednesday, March 19, 2014 11:45 PM >>> To: Gregory Mirsky >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: BFD v2? >>> >>>> >>>> Don't we have most of what Y.1731 offers available for MPLS networks? >>>> Did you mean the gaps in OAM for pure IP (non-MPLS) networks? >>> >>> And gaps in OAM for segment routed networks. >>> >>> Cheers, Manav >> > From nobody Fri Mar 21 17:54:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C49D1A0927 for ; Fri, 21 Mar 2014 17:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Inm1GrOQUR_H for ; Fri, 21 Mar 2014 17:54:47 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 122A11A0921 for ; Fri, 21 Mar 2014 17:54:47 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 2BFCF2AA0F; Sat, 22 Mar 2014 00:54:33 +0000 (GMT) Date: Fri, 21 Mar 2014 17:54:33 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , Santosh P K , "Bhatia, Manav (Manav)" , aldrin.ietf@gmail.com, MALLIK MUDIGONDA (mmudigon) Message-ID: <20140321175433104493.12bf1506@sniff.de> In-Reply-To: References: <20140319082501342601.778988ca@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B50DD@SG70YWXCHMBA05.zap.alcatel-lucent.com> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Zl9OHZQ2CeCQCzwjNYcegIa0rqE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Mar 2014 00:54:51 -0000 Hello, may I propose two things: * the authors of the draft write down what they have in mind for the D bit and publish it as -03 draft. Seems this will require a closer look at text details, so having it properly written down would be great * the discussion about the loop prevention should be completed, there are several proposals open. I would like to see what options are available. Sure, when the authors found a clean path for the "D" bit then this is somewhat academic but so far the discussion isn't finished, I think * the discriminator proposal. I will re-re-read it but have still problems to see why the my_discr of a packet received by the initiator is used for ... multiplexing? Something else? Sorry, I may be slow thinking here. * Girija proposal to use the state. As S-BFD introduces a new state machine this seems a valid proposal. Haven't seen any reply on the list (beside myself) * my "Required Min Echo RX Interval" proposal. If it's wrong or "weird" I would like to learn about it. * Greg's source UDP port idea (if I understand it right: reflector uses S-BFD port as source port + rule: never reflect when source port is the well-known S-BFD port). Basically a summary with why it won't work or at least pros/cons? Thanks & Regards, Marc On Thu, 20 Mar 2014 11:40:54 +0000, Nobo Akiya (nobo) wrote: > Hi Santosh, > >>> If implementation shares the local discriminator pool between BFD and >>> S-BFD, then session object located with your_discrim in incoming >>> packet will provide the bfd.SessionType. >> >> If pool is shared then how can your_disc help to get the sessionType? Did >> you mean not share pool between BFD and S-BFD? > > If we mimic the logic from multipoint draft, it would be something > like this. > > If the Your Discriminator field is nonzero > > Select a session based on the value of Your Discriminator. > If no session is found, the packet MUST be discarded. > > If bfd.SessionType is SBFDInitiator > > If Demand (D) bit is set, the packet MUST be discarded. > > Else if bfd.sessionType is SBFDReflector > > If Demand (D) bit is clear, the packet MUST be discarded. > > Else (non S-BFD) > > ... > > -Nobo > >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Thursday, March 20, 2014 7:01 AM >> To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger >> Cc: rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >> >> Nobo, >> I am confused with your statement below. Can you please clarify? >> >> >>> If implementation shares the local discriminator pool between BFD and >>> S-BFD, then session object located with your_discrim in incoming >>> packet will provide the bfd.SessionType. >> >> If pool is shared then how can your_disc help to get the sessionType? Did >> you mean not share pool between BFD and S-BFD? >> >> >> Thanks >> Santosh P K >> >> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>> Akiya >>> (nobo) >>> Sent: Thursday, March 20, 2014 6:20 AM >>> To: Bhatia, Manav (Manav); Marc Binderberger >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>> >>> Agree with Manav. >>> >>> One nit and one clarification. >>> >>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD >>>> reflector to reflect the S-BFD packets that it receives. The S-BFD >>>> reflectors should discard all packets that come with the D bit clear. >>> >>> s/The S-BFD reflectors should discard/The S-BFD reflectors MUST >>> discard/ >>> >>>> Please note that we will always know the S-BFD clients/reflectors >>>> since they would use a new UDP port. >>> >>> If implementation shares the local discriminator pool between BFD and >>> S-BFD, then session object located with your_discrim in incoming >>> packet will provide the bfd.SessionType. In this implementation, >>> non-IP based S-BFD can be supported without new G-Ach code point for >>> S-BFD. If implementation does not share the local discriminator pool >>> between BFD and S-BFD, then UDP port is required to first figure out >>> which table to lookup the session object, in which case will provide >>> BFD or S-BFD answer. In this implementation, non-IP based S- BFD will >>> require separate G-Ach code point than BFD (but one new G-Ach code >>> point for S-BFD should be sufficient). We should probably assume that the >> latter is needed. >>> >>> -Nobo >>> >>>> -----Original Message----- >>>> From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] >>>> Sent: Wednesday, March 19, 2014 8:01 PM >>>> To: Nobo Akiya (nobo); Marc Binderberger >>>> Cc: rtg-bfd@ietf.org >>>> Subject: RE: Loop Prevention in S-BFD >>>> (draft-akiya-bfd-seamless-base) >>>> >>>> Adding on top of what Nobo has already said. >>>> >>>> New bfd.SessionType variables can be defined for S-BFD clients and >>>> reflectors. The S-BFD draft will update the "D" bit based on the >>>> bfd.SessionType variable. This requires no other changes to 5880/5881. >>>> The S-BFD draft should unequivocally define what the "D" bit means >>>> in the context of the S-BFD packets. >>>> >>>> It can still be called the "D" (demand) bit and will be redefined to >>>> something like below: >>>> >>>> Demand (D) >>>> >>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD >>>> reflector to reflect the S-BFD packets that it receives. The S-BFD >>>> reflectors should discard all packets that come with the D bit clear. >>>> >>>> S-BFD clients MUST always ignore packets coming with the "D" bit set. >>>> >>>> Please note that we will always know the S-BFD clients/reflectors >>>> since they would use a new UDP port. >>>> >>>> I like this approach over the one that uses descriminator values >>>> simply because examining a bit to detect a loop is much easier to >>>> implement in hardware. Looking at the descriminator values and then >>>> detecting a loop cannot be easily done in HW. >>>> >>>> Since the approach using the "D" bit seems to be acceptable to quite >>>> a few folks here, I would like to understand the reason, if any, for >> opposing this. >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>>> Akiya >>>>> (nobo) >>>>> Sent: Wednesday, March 19, 2014 9:22 PM >>>>> To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) >>>>> Cc: rtg-bfd@ietf.org >>>>> Subject: RE: Loop Prevention in S-BFD >>>>> (draft-akiya-bfd-seamless-base) >>>>> >>>>>> we will see how the discussion goes although I personally do not >>>>> think the >>>>>> M and D bit can be compared. Seems other people didn't see D a >>>>>> good >>>>> fit >>>>>> (formally) either. Anyway, I'll have a look again at the "M" bit >>>>>> and >>>>> the >>>>>> multipoint draft. >>>>> >>>>> You are right Marc, M and D bit alone is not a good comparison. >>>>> However, it's not just M bit that's updated in the multipoint draft. >>>>> Multipoint draft updates M bit, introduces new state variables >>>>> (bfd.SessionType) and updates RX procedures. >>>>> >>>>> Take a look at following sections in the multipoint draft. >>>>> 4.4.1. New State Variable >>>>> 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing >>>>> BFD Control Packets >>>>> >>>>> Since your_discrim in S-BFD (both directions) is never zero(0), >>>>> bfd.SessionType is derivable for all cases. And D bit check can be >>>>> added for new bfd.SessionType values defined for S-BFD (both >>>>> directions), as part of RX procedures. Not only this approach >>>>> doesn't require BFDv2, it also addresses the point raised by Greg (i.e. >>>>> support for non-IP based S-BFD). >>>>> >>>>> -Nobo >>>>> >>>>>> -----Original Message----- >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>> Sent: Wednesday, March 19, 2014 11:25 AM >>>>>> To: MALLIK MUDIGONDA (mmudigon) >>>>>> Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- >>>>>> bfd@ietf.org >>>>>> Subject: Re: Loop Prevention in S-BFD >>>>>> (draft-akiya-bfd-seamless-base) >>>>>> >>>>>> Hello Mallik, >>>>>> >>>>>> we will see how the discussion goes although I personally do not >>>>> think the >>>>>> M and D bit can be compared. Seems other people didn't see D a >>>>>> good >>>>> fit >>>>>> (formally) either. Anyway, I'll have a look again at the "M" bit >>>>>> and >>>>> the >>>>>> multipoint draft. >>>>>> >>>>>> >>>>>>> Regarding the discriminator usage for solving this, we do not >>>>>>> want >>>>> to >>>>>>> put any specific restrictions on the way discriminators are used. >>>>>> >>>>>> what restriction? >>>>>> >>>>>>> That's the reason the thread stopped there. Can't think of any >>>>>>> particular use case where MyDisc is used to demux, but that's >>>>>>> the reason not to impose this restriction. >>>>>> >>>>>> Huh?! There is some misunderstanding here, so let me repeat the >>>>>> discriminator idea: >>>>>> >>>>>> (1) S-BFD initiator R1 sends a BFD packet to reflector R2 >>>>>> >>>>>> (2) Reflector R2 copies the my_discr from incoming packet into >>>>> your_discr >>>>>> for outgoing packet. >>>>>> >>>>>> (3) Reflector R2 copies one of his local discriminator values >>>>>> into >>>>> my_discr of >>>>>> the outgoing packet. This local discriminator is not a >>>>>> "reflector discriminator" of R2. >>>>>> >>>>>> (4) The S-BFD initiator R1 is doing normal BFD operations by >>>>>> looking >>>>> into the >>>>>> your_discr of the reflected packet to demux. >>>>>> >>>>>> Especially R1 is not using "my_discr" of the reflected packet to >>>>> demux. >>>>>> >>>>>> The point is: when someone is injecting an "endless loop" packet >>>>>> by >>>>> using >>>>>> the "reflector discriminator" of R1 as my_discr, the reflector >>>>> discriminator of >>>>>> R2 as your_discr and sends the packet to R2 then the steps above >>>>> result in a >>>>>> packet >>>>>> >>>>>> attacker -> R2 -> R1 -> R2 -> drop/punt >>>>>> >>>>>> So after maximum 2 reflections the loop is broken. >>>>>> >>>>>> >>>>>> Regards, Marc >>>>>> >>>>>> >>> >>> >> > From nobody Sun Mar 23 07:56:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4C21A6FC5 for ; Sun, 23 Mar 2014 07:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.811 X-Spam-Level: X-Spam-Status: No, score=-6.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkF7lof9hrAk for ; Sun, 23 Mar 2014 07:56:24 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id BB4341A6FC3 for ; Sun, 23 Mar 2014 07:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12731; q=dns/txt; s=iport; t=1395586583; x=1396796183; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lNb72A66+c4bMORwFZohFmJRD4Etpv82KCGuAarStv0=; b=YTg5iBZrZ2Bsa9FZPWGCCTCd6z91uC6Y2sHP+8IDUU4+UP75y1rPuGrG apAy5PGKgu5dxdpB7xU7HIQch8eIWD3EdDglpHGR0y0T/GU8QTDRGeS6k U3bMsrtIKqZUfAoTuFrD1Q8xbf4HyHqJKCvXjN3lyo6rf8oOWekjrcG6j A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACT1LlOtJV2Z/2dsb2JhbABZgmUhO1fCboEOFnSCJQEBAQQnEz8MBAIBCBEEAQEBChQJByERFAkIAgQBDQUIE4dKAxEBDMYSDYcFF4lMgxGBbDEHBoMegRQEll2DH4s2hUmDLYIr X-IronPort-AV: E=Sophos;i="4.97,714,1389744000"; d="scan'208";a="29690479" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 23 Mar 2014 14:56:21 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2NEuLxj018682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Mar 2014 14:56:21 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.03.0123.003; Sun, 23 Mar 2014 09:56:20 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Santosh P K , "Bhatia, Manav (Manav)" , "aldrin.ietf@gmail.com" , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAE90UIAAFnEggAAgw9CAAMIGAIAASljQgAIwxID//d6/0A== Date: Sun, 23 Mar 2014 14:56:20 +0000 Message-ID: References: <20140319082501342601.778988ca@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B50DD@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140321175433104493.12bf1506@sniff.de> In-Reply-To: <20140321175433104493.12bf1506@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RtCSV67M3plFb8f8lJqGhvz3fxM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 Mar 2014 14:56:27 -0000 Hi Marc, et al, > * the authors of the draft write down what they have in mind for the D bi= t > and publish it as -03 draft. Seems this will require a closer look at tex= t > details, so having it properly written down would be great There has been many responses around this particular point (and thanks to a= ll who has responded!), it would be a good idea to have a revised document = which provides a new starting baseline for further discussions. Although at= this point, *rough consensus* does seem to be D-bit approach. We would pla= ce the D-bit as the solution, but place all other alternatives in the Appen= dix. The other thing which I would like to point out is that, we are actively di= scussing the solution but not the use-cases ... many of us are engineers!? = :) What would be helpful to take S-BFD to the next step (i.e. re-chartering= and WG adoption) is for us to discuss more of use-cases on the list. Thus I'd like to direct some of the attention to the S-BFD use-case draft. http://tools.ietf.org/html/draft-aldrin-bfd-seamless-use-case-00 Do you [not] agree with use-cases listed? Do you see any other use-cases which should be added? Even a comment such as "I agree with this use-case from the draft" is very = helpful. -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, March 21, 2014 8:55 PM > To: Nobo Akiya (nobo); Santosh P K; Bhatia, Manav (Manav); > aldrin.ietf@gmail.com; MALLIK MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Hello, >=20 > may I propose two things: >=20 > * the authors of the draft write down what they have in mind for the D bi= t > and publish it as -03 draft. Seems this will require a closer look at tex= t > details, so having it properly written down would be great >=20 >=20 > * the discussion about the loop prevention should be completed, there are > several proposals open. I would like to see what options are available. S= ure, > when the authors found a clean path for the "D" bit then this is somewhat > academic but so far the discussion isn't finished, I think >=20 > * the discriminator proposal. I will re-re-read it but have still probl= ems to > see why the my_discr of a packet received by the initiator is used for ..= . > multiplexing? Something else? Sorry, I may be slow thinking here. >=20 > * Girija proposal to use the state. As S-BFD introduces a new state mac= hine > this seems a valid proposal. Haven't seen any reply on the list (beside > myself) >=20 > * my "Required Min Echo RX Interval" proposal. If it's wrong or "weird"= I > would like to learn about it. >=20 > * Greg's source UDP port idea (if I understand it right: reflector uses= S-BFD > port as source port + rule: never reflect when source port is the well-kn= own > S-BFD port). >=20 >=20 > Basically a summary with why it won't work or at least pros/cons? >=20 >=20 >=20 > Thanks & Regards, > Marc >=20 >=20 >=20 >=20 >=20 > On Thu, 20 Mar 2014 11:40:54 +0000, Nobo Akiya (nobo) wrote: > > Hi Santosh, > > > >>> If implementation shares the local discriminator pool between BFD > >>> and S-BFD, then session object located with your_discrim in incoming > >>> packet will provide the bfd.SessionType. > >> > >> If pool is shared then how can your_disc help to get the sessionType? > >> Did you mean not share pool between BFD and S-BFD? > > > > If we mimic the logic from multipoint draft, it would be something > > like this. > > > > If the Your Discriminator field is nonzero > > > > Select a session based on the value of Your Discriminator. > > If no session is found, the packet MUST be discarded. > > > > If bfd.SessionType is SBFDInitiator > > > > If Demand (D) bit is set, the packet MUST be discarded. > > > > Else if bfd.sessionType is SBFDReflector > > > > If Demand (D) bit is clear, the packet MUST be discarded. > > > > Else (non S-BFD) > > > > ... > > > > -Nobo > > > >> -----Original Message----- > >> From: Santosh P K [mailto:santoshpk@juniper.net] > >> Sent: Thursday, March 20, 2014 7:01 AM > >> To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger > >> Cc: rtg-bfd@ietf.org > >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> Nobo, > >> I am confused with your statement below. Can you please clarify? > >> > >> > >>> If implementation shares the local discriminator pool between BFD > >>> and S-BFD, then session object located with your_discrim in incoming > >>> packet will provide the bfd.SessionType. > >> > >> If pool is shared then how can your_disc help to get the sessionType? > >> Did you mean not share pool between BFD and S-BFD? > >> > >> > >> Thanks > >> Santosh P K > >> > >> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>> Akiya > >>> (nobo) > >>> Sent: Thursday, March 20, 2014 6:20 AM > >>> To: Bhatia, Manav (Manav); Marc Binderberger > >>> Cc: rtg-bfd@ietf.org > >>> Subject: RE: Loop Prevention in S-BFD > >>> (draft-akiya-bfd-seamless-base) > >>> > >>> Agree with Manav. > >>> > >>> One nit and one clarification. > >>> > >>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD > >>>> reflector to reflect the S-BFD packets that it receives. The S-BFD > >>>> reflectors should discard all packets that come with the D bit clear= . > >>> > >>> s/The S-BFD reflectors should discard/The S-BFD reflectors MUST > >>> discard/ > >>> > >>>> Please note that we will always know the S-BFD clients/reflectors > >>>> since they would use a new UDP port. > >>> > >>> If implementation shares the local discriminator pool between BFD > >>> and S-BFD, then session object located with your_discrim in incoming > >>> packet will provide the bfd.SessionType. In this implementation, > >>> non-IP based S-BFD can be supported without new G-Ach code point for > >>> S-BFD. If implementation does not share the local discriminator pool > >>> between BFD and S-BFD, then UDP port is required to first figure out > >>> which table to lookup the session object, in which case will provide > >>> BFD or S-BFD answer. In this implementation, non-IP based S- BFD > >>> will require separate G-Ach code point than BFD (but one new G-Ach > >>> code point for S-BFD should be sufficient). We should probably > >>> assume that the > >> latter is needed. > >>> > >>> -Nobo > >>> > >>>> -----Original Message----- > >>>> From: Bhatia, Manav (Manav) > >>>> [mailto:manav.bhatia@alcatel-lucent.com] > >>>> Sent: Wednesday, March 19, 2014 8:01 PM > >>>> To: Nobo Akiya (nobo); Marc Binderberger > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: RE: Loop Prevention in S-BFD > >>>> (draft-akiya-bfd-seamless-base) > >>>> > >>>> Adding on top of what Nobo has already said. > >>>> > >>>> New bfd.SessionType variables can be defined for S-BFD clients and > >>>> reflectors. The S-BFD draft will update the "D" bit based on the > >>>> bfd.SessionType variable. This requires no other changes to 5880/588= 1. > >>>> The S-BFD draft should unequivocally define what the "D" bit means > >>>> in the context of the S-BFD packets. > >>>> > >>>> It can still be called the "D" (demand) bit and will be redefined > >>>> to something like below: > >>>> > >>>> Demand (D) > >>>> > >>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD > >>>> reflector to reflect the S-BFD packets that it receives. The S-BFD > >>>> reflectors should discard all packets that come with the D bit clear= . > >>>> > >>>> S-BFD clients MUST always ignore packets coming with the "D" bit set= . > >>>> > >>>> Please note that we will always know the S-BFD clients/reflectors > >>>> since they would use a new UDP port. > >>>> > >>>> I like this approach over the one that uses descriminator values > >>>> simply because examining a bit to detect a loop is much easier to > >>>> implement in hardware. Looking at the descriminator values and then > >>>> detecting a loop cannot be easily done in HW. > >>>> > >>>> Since the approach using the "D" bit seems to be acceptable to > >>>> quite a few folks here, I would like to understand the reason, if > >>>> any, for > >> opposing this. > >>>> > >>>> Cheers, Manav > >>>> > >>>>> -----Original Message----- > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>>>> Akiya > >>>>> (nobo) > >>>>> Sent: Wednesday, March 19, 2014 9:22 PM > >>>>> To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) > >>>>> Cc: rtg-bfd@ietf.org > >>>>> Subject: RE: Loop Prevention in S-BFD > >>>>> (draft-akiya-bfd-seamless-base) > >>>>> > >>>>>> we will see how the discussion goes although I personally do not > >>>>> think the > >>>>>> M and D bit can be compared. Seems other people didn't see D a > >>>>>> good > >>>>> fit > >>>>>> (formally) either. Anyway, I'll have a look again at the "M" bit > >>>>>> and > >>>>> the > >>>>>> multipoint draft. > >>>>> > >>>>> You are right Marc, M and D bit alone is not a good comparison. > >>>>> However, it's not just M bit that's updated in the multipoint draft= . > >>>>> Multipoint draft updates M bit, introduces new state variables > >>>>> (bfd.SessionType) and updates RX procedures. > >>>>> > >>>>> Take a look at following sections in the multipoint draft. > >>>>> 4.4.1. New State Variable > >>>>> 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing > >>>>> BFD Control Packets > >>>>> > >>>>> Since your_discrim in S-BFD (both directions) is never zero(0), > >>>>> bfd.SessionType is derivable for all cases. And D bit check can be > >>>>> added for new bfd.SessionType values defined for S-BFD (both > >>>>> directions), as part of RX procedures. Not only this approach > >>>>> doesn't require BFDv2, it also addresses the point raised by Greg (= i.e. > >>>>> support for non-IP based S-BFD). > >>>>> > >>>>> -Nobo > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>>>> Sent: Wednesday, March 19, 2014 11:25 AM > >>>>>> To: MALLIK MUDIGONDA (mmudigon) > >>>>>> Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > >>>>>> bfd@ietf.org > >>>>>> Subject: Re: Loop Prevention in S-BFD > >>>>>> (draft-akiya-bfd-seamless-base) > >>>>>> > >>>>>> Hello Mallik, > >>>>>> > >>>>>> we will see how the discussion goes although I personally do not > >>>>> think the > >>>>>> M and D bit can be compared. Seems other people didn't see D a > >>>>>> good > >>>>> fit > >>>>>> (formally) either. Anyway, I'll have a look again at the "M" bit > >>>>>> and > >>>>> the > >>>>>> multipoint draft. > >>>>>> > >>>>>> > >>>>>>> Regarding the discriminator usage for solving this, we do not > >>>>>>> want > >>>>> to > >>>>>>> put any specific restrictions on the way discriminators are used. > >>>>>> > >>>>>> what restriction? > >>>>>> > >>>>>>> That's the reason the thread stopped there. Can't think of any > >>>>>>> particular use case where MyDisc is used to demux, but that's > >>>>>>> the reason not to impose this restriction. > >>>>>> > >>>>>> Huh?! There is some misunderstanding here, so let me repeat the > >>>>>> discriminator idea: > >>>>>> > >>>>>> (1) S-BFD initiator R1 sends a BFD packet to reflector R2 > >>>>>> > >>>>>> (2) Reflector R2 copies the my_discr from incoming packet into > >>>>> your_discr > >>>>>> for outgoing packet. > >>>>>> > >>>>>> (3) Reflector R2 copies one of his local discriminator values > >>>>>> into > >>>>> my_discr of > >>>>>> the outgoing packet. This local discriminator is not a "reflector > >>>>>> discriminator" of R2. > >>>>>> > >>>>>> (4) The S-BFD initiator R1 is doing normal BFD operations by > >>>>>> looking > >>>>> into the > >>>>>> your_discr of the reflected packet to demux. > >>>>>> > >>>>>> Especially R1 is not using "my_discr" of the reflected packet to > >>>>> demux. > >>>>>> > >>>>>> The point is: when someone is injecting an "endless loop" packet > >>>>>> by > >>>>> using > >>>>>> the "reflector discriminator" of R1 as my_discr, the reflector > >>>>> discriminator of > >>>>>> R2 as your_discr and sends the packet to R2 then the steps above > >>>>> result in a > >>>>>> packet > >>>>>> > >>>>>> attacker -> R2 -> R1 -> R2 -> drop/punt > >>>>>> > >>>>>> So after maximum 2 reflections the loop is broken. > >>>>>> > >>>>>> > >>>>>> Regards, Marc > >>>>>> > >>>>>> > >>> > >>> > >> > > From nobody Sun Mar 23 08:47:01 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C8B1A0760 for ; Sun, 23 Mar 2014 08:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfU0W0uBxwO4 for ; Sun, 23 Mar 2014 08:46:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 364981A03FB for ; Sun, 23 Mar 2014 08:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3907; q=dns/txt; s=iport; t=1395589618; x=1396799218; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aaTen9dGlzL6+UZyj9cXNDm3kL/4LrtUwqP/rCDrVcY=; b=h6DLebT8RXDgQ24k1Qx4+2Xw/S50A5Jir/pXdTP/F5AxXCwbC5Nf6SkZ uor1jZ8q6vWX43YknjruLQ1nfw9E39ESOr9vST9+GFrR8xoTWEnVtSQ4A t+QnwfMJuevl+KpEzBQ630jgM9pvUFeIdIlXwKu2p/cbSCMYNYAaS2o+n 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAI0BL1OtJXG+/2dsb2JhbABZgmUhO1fCboEOFnSCJQEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIE4deAQzNKheOSTEHBoMegRQEmXyQf4Mtgis X-IronPort-AV: E=Sophos;i="4.97,714,1389744000"; d="scan'208";a="29683950" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 23 Mar 2014 15:46:57 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2NFkv6V002251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Mar 2014 15:46:57 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.03.0123.003; Sun, 23 Mar 2014 10:46:56 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "Bhatia, Manav (Manav)" , "Marc Binderberger (marc@sniff.de)" Subject: RE: BFD v2? Thread-Topic: BFD v2? Thread-Index: AQHPQ5GYGUdJHidalE+yCfRa42HcrprpflgAgAArJ4CAAB3HAIAAEyQAgAACBQCAAASUgIAABJqAgACH9QCABGLxcA== Date: Sun, 23 Mar 2014 15:46:56 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D339D408F@xmb-rcd-x15.cisco.com> <20140317103630501812.259d0463@sniff.de> <20140317182952.GB13937@pfrc> <20140317183601756886.ce85139a@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B296E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140318104625080456.bebea936@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B3F45@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140319163739.GB30410@pfrc> <20140319180758624457.0dc0ae90@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B5276@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B2D@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B553E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E5B556D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788B81@eusaamb103.ericsson.se> <20211F91F544D247976D84C5D778A4C32E5B55EB@SG70YWXCHMBA05.zap.alcatel-lucent.com> <7347100B5761DC41A166AC17F22DF1121B788D8A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B788D8A@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xe_Wgs78aPDgecWkKkmexvwrOno Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 Mar 2014 15:47:00 -0000 I *think* there are things which protocols/people are *hoping/wanting* OAM = to be able to do (perhaps by BFD, perhaps X together with BFD or perhaps no= t involving BFD at all) ... small[er] items not mentioned. 1. Rapid verification of path/service availability. 2. In-band monitoring via controller device. 3. Per ECMP/UCMP path in-band monitoring. 4. Controlling the return path of in-band monitoring. 5. Deterministically differentiating link-failure vs. node-failure. [1-3] Solved by S-BFD (3 solved only with specific hashing (ex: EL)). [4] http://datatracker.ietf.org/doc/rfc7110/ provides one solution, but the= re is no generic solution. [5] Nothing out there? I agree that v2 definition should be driven by specific requirements. Those= can be driven by vendors or operators, but we need to have specific requir= ements before jumping on to defining the v2. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory > Mirsky > Sent: Thursday, March 20, 2014 11:24 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Manav, > regarding IP Performance Measurement I can point to IPPM WG. Everything > that is related to measurement of performance of IP transports (UDP, TCP) > and IP-based applications is in scope of IPPM WG. As mentioned earlier, > OWAMP and TWAMP protocols support measurement of delay and delay > variation both one-way and two-way metrics. As for link trace, I think th= at > traceroute does that already. > The problem of "in-band" OAM does exist and Nobo and I recently talked > about it on this thread. I agree with Nobo that if an operator needs in-b= and > OAM over ECMP then hashing must exclude Destination and Source UDP > ports. > What's left? That is good question, particularly for operators that plan = to use > Segment Routing with IPv6 dataplane. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Thursday, March 20, 2014 12:18 AM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Greg, >=20 > Ideally the demand should come from the operators in case they need > enhanced IP OAM capabilities (loss measurement, an equivalent of a link > trace, etc) for pure IP networks. Has anybody ever asked for this? I am a= ware > of the ECMP issue where the IP OAM does not follow the traffic. But besid= es > that, is there anything else that folks have been asking for? >=20 > Cheers, Manav >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 20, 2014 12:31 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD v2? > > > > Hi Manav, > > right, MPLS OAM is much functionally closer to Y.1731 though there are > > some missing functions among them experimental and vendor-specific > > might be of interest for us. But I'll note that MPLS Performance > > Measurement RFC 6374 and MPLS-TP profile RFC 6375 need metrics > > definitions at least. > > Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, > > considering that MPLS dataplane may make MPLS OAM re-usable in > SPRING. > > (That to be seen after we finish SPRING OAM Requirements and gap > > analysis). > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > Sent: Wednesday, March 19, 2014 11:45 PM > > To: Gregory Mirsky > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD v2? > > > > > > > > Don't we have most of what Y.1731 offers available for MPLS networks? > > > Did you mean the gaps in OAM for pure IP (non-MPLS) networks? > > > > And gaps in OAM for segment routed networks. > > > > Cheers, Manav From nobody Sun Mar 23 11:19:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129731A6FFD for ; Sun, 23 Mar 2014 11:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWnLfuJuPpI2 for ; Sun, 23 Mar 2014 11:19:14 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1881A6FF8 for ; Sun, 23 Mar 2014 11:19:14 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-a0-532f22b44ec2 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 76.D4.11484.4B22F235; Sun, 23 Mar 2014 19:06:44 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Sun, 23 Mar 2014 14:19:07 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "Bhatia, Manav (Manav)" , "Marc Binderberger (marc@sniff.de)" Subject: S-BFD Requirements (RE: BFD v2?) Thread-Topic: S-BFD Requirements (RE: BFD v2?) Thread-Index: Ac9Gw02uhYhqw2cmTae2CKkqHWpWOA== Date: Sun, 23 Mar 2014 18:19:06 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B789F0B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPiO4WJf1gg1m3lSzm3LvHajH7yn9m i9kd8Raf/2xjdGDxaH22l9Vjyu+NrB5Llvxk8mhd3c0SwBLFZZOSmpNZllqkb5fAlfH99QK2 gmcqFS8vLWBtYDwn28XIySEhYCLxctY5RghbTOLCvfVsXYxcHEICRxglDt9bwAzhLGeU+Pep CayKTcBI4sXGHnaQhIjAHEaJS63L2EESzAKaEk0nPoPZwkD2h8/f2EBsEQE9iVN/HjLC2JP+ zGQBsVkEVCUeTZ3NBGLzCvhKHNt4DKyGEeiM76fWMEHMFJe49WQ+E8R5AhJL9pxnhrBFJV4+ /scKYStJfPw9H+oGHYkFuz+xQdjaEssWvmaGmC8ocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCy rGLkKC1OLctNNzLcxAiMj2MSbI47GBd8sjzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxl1zlv833u38pCNu+1ahXM2EY9MfBmhqnmU8c0vrnnz48fdea558PDXNr3uS uMvjI/vzGC8m8C6OPDXXIpJ5luzDB49d8/J+PtqupXd0p66Z1k4OX5Oj+YVywnc/3BT5vE5k 3703h6R8Gk7y7Tw66ajBvXXbvFgFONb5/4hV/Xf+5Ma/d/TmMKgpsRRnJBpqMRcVJwIA7p6W Vl0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/b2TZONsY4KhZDt875LL96Wvp69o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 Mar 2014 18:19:17 -0000 Hi Nobo, I completely agree that we must always keep requirements in perspective. For #2 can we just say "in-band continuity check"? #3 - I think that there's no way to ensure which of ECMP/UCMP sub-paths bei= ng monitored at any given time. I believe that as case of composite link EC= MP/UCMP should be monitored on composite link level, e.g. like micro-BFD on= LAG. #4 - I believe that almost all required instrumentation is there already #5 - that is, IMHO, unnecessary. Regards, Greg -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Sunday, March 23, 2014 8:47 AM To: Gregory Mirsky; Bhatia, Manav (Manav); Marc Binderberger (marc@sniff.de= ) Cc: rtg-bfd@ietf.org Subject: RE: BFD v2? I *think* there are things which protocols/people are *hoping/wanting* OAM = to be able to do (perhaps by BFD, perhaps X together with BFD or perhaps no= t involving BFD at all) ... small[er] items not mentioned. 1. Rapid verification of path/service availability. 2. In-band monitoring via controller device. 3. Per ECMP/UCMP path in-band monitoring. 4. Controlling the return path of in-band monitoring. 5. Deterministically differentiating link-failure vs. node-failure. [1-3] Solved by S-BFD (3 solved only with specific hashing (ex: EL)). [4] http://datatracker.ietf.org/doc/rfc7110/ provides one solution, but the= re is no generic solution. [5] Nothing out there? I agree that v2 definition should be driven by specific requirements. Those= can be driven by vendors or operators, but we need to have specific requir= ements before jumping on to defining the v2. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory=20 > Mirsky > Sent: Thursday, March 20, 2014 11:24 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Manav, > regarding IP Performance Measurement I can point to IPPM WG.=20 > Everything that is related to measurement of performance of IP=20 > transports (UDP, TCP) and IP-based applications is in scope of IPPM=20 > WG. As mentioned earlier, OWAMP and TWAMP protocols support=20 > measurement of delay and delay variation both one-way and two-way=20 > metrics. As for link trace, I think that traceroute does that already. > The problem of "in-band" OAM does exist and Nobo and I recently talked=20 > about it on this thread. I agree with Nobo that if an operator needs=20 > in-band OAM over ECMP then hashing must exclude Destination and Source=20 > UDP ports. > What's left? That is good question, particularly for operators that=20 > plan to use Segment Routing with IPv6 dataplane. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Thursday, March 20, 2014 12:18 AM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 > Hi Greg, >=20 > Ideally the demand should come from the operators in case they need=20 > enhanced IP OAM capabilities (loss measurement, an equivalent of a=20 > link trace, etc) for pure IP networks. Has anybody ever asked for=20 > this? I am aware of the ECMP issue where the IP OAM does not follow=20 > the traffic. But besides that, is there anything else that folks have bee= n asking for? >=20 > Cheers, Manav >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 20, 2014 12:31 PM > > To: Bhatia, Manav (Manav) > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD v2? > > > > Hi Manav, > > right, MPLS OAM is much functionally closer to Y.1731 though there=20 > > are some missing functions among them experimental and=20 > > vendor-specific might be of interest for us. But I'll note that MPLS=20 > > Performance Measurement RFC 6374 and MPLS-TP profile RFC 6375 need=20 > > metrics definitions at least. > > Yes, I did mean non-MPLS IP. Segment Routed networks - no so much,=20 > > considering that MPLS dataplane may make MPLS OAM re-usable in > SPRING. > > (That to be seen after we finish SPRING OAM Requirements and gap=20 > > analysis). > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > Sent: Wednesday, March 19, 2014 11:45 PM > > To: Gregory Mirsky > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD v2? > > > > > > > > Don't we have most of what Y.1731 offers available for MPLS networks? > > > Did you mean the gaps in OAM for pure IP (non-MPLS) networks? > > > > And gaps in OAM for segment routed networks. > > > > Cheers, Manav From nobody Mon Mar 24 06:15:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220861A022C for ; Mon, 24 Mar 2014 06:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky1JuFqmdA8b for ; Mon, 24 Mar 2014 06:15:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7008B1A0244 for ; Mon, 24 Mar 2014 06:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6929; q=dns/txt; s=iport; t=1395666839; x=1396876439; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZRlV8h8nq02avajL99oCBrXv75XLZfq128Zudg90f/o=; b=b5Kco2IZ6ZAY4vAMxBJ9sVidwzwWWdRNh2PL/FSBZGmDo+UVGaSRKEpM FqINNRKSdqpGiJujMVxI7Ht7DKrYKlUv2SfouY6TtLM6hFVOoqxF9tqeC Eg9v36xxsYQRYoj9pwwZSlAdYpDPK1TwU3E8S46H9gcvfJ4x2avXx7qsN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAGkuMFOtJV2b/2dsb2JhbABZgmUhO1fCcoEWFnSCJQEBAQMBOj8FBwQCAQgRBAEBCxQJBzIUCQgBAQQBDQUIEgGHVggBDM4AF4lMhH0xBwaDHoEUBJl8kH+DLYIr X-IronPort-AV: E=Sophos;i="4.97,720,1389744000"; d="scan'208";a="29865113" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 24 Mar 2014 13:13:56 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2ODDuY3030550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 13:13:56 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.03.0123.003; Mon, 24 Mar 2014 08:13:56 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "Bhatia, Manav (Manav)" , "Marc Binderberger (marc@sniff.de)" Subject: RE: S-BFD Requirements (RE: BFD v2?) Thread-Topic: S-BFD Requirements (RE: BFD v2?) Thread-Index: Ac9Gw02uhYhqw2cmTae2CKkqHWpWOAAm3cXw Date: Mon, 24 Mar 2014 13:13:55 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B789F0B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B789F0B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qm2dk4UkZkTdSnpaByKWbypdp84 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 24 Mar 2014 13:15:41 -0000 Hi Greg, > I completely agree that we must always keep requirements in perspective. > For #2 can we just say "in-band continuity check"? I think that's a fair naming. > #3 - I think that there's no way to ensure which of ECMP/UCMP sub-paths > being monitored at any given time. I agree, best we can do is to have frequent fresh rate to update the paths = (and entropies). > I believe that as case of composite link > ECMP/UCMP should be monitored on composite link level, e.g. like micro- > BFD on LAG. That approach definitely fits better in some scenarios, and provides better= scalability (i.e. distributes monitor packet processing). Although my one = concern with that approach is that we will not be truly testing the packet = path into each composite and out from each composite (i.e. monitor packets = are locally generated from composite ingress and terminated on composite eg= ress). If we want the coverage to include such, then doing the monitoring L= SP end-to-end with LSP path trace for entropy discovery may be the way to g= o (with LSRs employing EL load balancing). For IP based network, what you s= uggested may be the only way at this moment (with composite ingress pre-rou= ting into each composite link), as there is no tools to discover the entrop= ies yet. > #4 - I believe that almost all required instrumentation is there already That's a good news. Can you send me list of techniques that are on your rad= ar? > #5 - that is, IMHO, unnecessary. I hope so, it's a very difficult problem ... I do see some standard track d= rafts, that rely on node failure detection, progressing. Let's see if any r= equirements comes flying into BFD WG direction [or not]. -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Sunday, March 23, 2014 2:19 PM > To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger > (marc@sniff.de) > Cc: rtg-bfd@ietf.org > Subject: S-BFD Requirements (RE: BFD v2?) >=20 > Hi Nobo, > I completely agree that we must always keep requirements in perspective. > For #2 can we just say "in-band continuity check"? > #3 - I think that there's no way to ensure which of ECMP/UCMP sub-paths > being monitored at any given time. I believe that as case of composite li= nk > ECMP/UCMP should be monitored on composite link level, e.g. like micro- > BFD on LAG. > #4 - I believe that almost all required instrumentation is there already > #5 - that is, IMHO, unnecessary. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Sunday, March 23, 2014 8:47 AM > To: Gregory Mirsky; Bhatia, Manav (Manav); Marc Binderberger > (marc@sniff.de) > Cc: rtg-bfd@ietf.org > Subject: RE: BFD v2? >=20 >=20 > I *think* there are things which protocols/people are *hoping/wanting* > OAM to be able to do (perhaps by BFD, perhaps X together with BFD or > perhaps not involving BFD at all) ... small[er] items not mentioned. >=20 > 1. Rapid verification of path/service availability. > 2. In-band monitoring via controller device. > 3. Per ECMP/UCMP path in-band monitoring. > 4. Controlling the return path of in-band monitoring. > 5. Deterministically differentiating link-failure vs. node-failure. >=20 > [1-3] Solved by S-BFD (3 solved only with specific hashing (ex: EL)). >=20 > [4] http://datatracker.ietf.org/doc/rfc7110/ provides one solution, but t= here > is no generic solution. >=20 > [5] Nothing out there? >=20 > I agree that v2 definition should be driven by specific requirements. Tho= se > can be driven by vendors or operators, but we need to have specific > requirements before jumping on to defining the v2. >=20 > -Nobo >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory > > Mirsky > > Sent: Thursday, March 20, 2014 11:24 AM > > To: Bhatia, Manav (Manav) > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD v2? > > > > Hi Manav, > > regarding IP Performance Measurement I can point to IPPM WG. > > Everything that is related to measurement of performance of IP > > transports (UDP, TCP) and IP-based applications is in scope of IPPM > > WG. As mentioned earlier, OWAMP and TWAMP protocols support > > measurement of delay and delay variation both one-way and two-way > > metrics. As for link trace, I think that traceroute does that already. > > The problem of "in-band" OAM does exist and Nobo and I recently talked > > about it on this thread. I agree with Nobo that if an operator needs > > in-band OAM over ECMP then hashing must exclude Destination and > Source > > UDP ports. > > What's left? That is good question, particularly for operators that > > plan to use Segment Routing with IPv6 dataplane. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > Sent: Thursday, March 20, 2014 12:18 AM > > To: Gregory Mirsky > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD v2? > > > > Hi Greg, > > > > Ideally the demand should come from the operators in case they need > > enhanced IP OAM capabilities (loss measurement, an equivalent of a > > link trace, etc) for pure IP networks. Has anybody ever asked for > > this? I am aware of the ECMP issue where the IP OAM does not follow > > the traffic. But besides that, is there anything else that folks have b= een > asking for? > > > > Cheers, Manav > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Thursday, March 20, 2014 12:31 PM > > > To: Bhatia, Manav (Manav) > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: BFD v2? > > > > > > Hi Manav, > > > right, MPLS OAM is much functionally closer to Y.1731 though there > > > are some missing functions among them experimental and > > > vendor-specific might be of interest for us. But I'll note that MPLS > > > Performance Measurement RFC 6374 and MPLS-TP profile RFC 6375 need > > > metrics definitions at least. > > > Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, > > > considering that MPLS dataplane may make MPLS OAM re-usable in > > SPRING. > > > (That to be seen after we finish SPRING OAM Requirements and gap > > > analysis). > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > > Sent: Wednesday, March 19, 2014 11:45 PM > > > To: Gregory Mirsky > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: BFD v2? > > > > > > > > > > > Don't we have most of what Y.1731 offers available for MPLS network= s? > > > > Did you mean the gaps in OAM for pure IP (non-MPLS) networks? > > > > > > And gaps in OAM for segment routed networks. > > > > > > Cheers, Manav From nobody Mon Mar 24 11:32:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76A61A0271 for ; Mon, 24 Mar 2014 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[BAYES_80=2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfyL152NqHKF for ; Mon, 24 Mar 2014 11:32:30 -0700 (PDT) Received: from bay0-omc4-s20.bay0.hotmail.com (bay0-omc4-s20.bay0.hotmail.com [65.54.190.222]) by ietfa.amsl.com (Postfix) with ESMTP id A10CF1A026F for ; Mon, 24 Mar 2014 11:32:30 -0700 (PDT) Received: from BAY176-W24 ([65.54.190.200]) by bay0-omc4-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Mar 2014 11:32:29 -0700 X-TMN: [zhbBxbyFE2rvsM/jkadGDD/2Ng+al5e9] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_9987d60d-779a-4a18-9ec1-bb168775fb77_" From: Ashesh Mishra To: "rtg-bfd@ietf.org" Subject: Poll Sequence in BFD Date: Mon, 24 Mar 2014 11:32:30 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Mar 2014 18:32:29.0995 (UTC) FILETIME=[69EB2FB0:01CF478F] Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/pnwfPrlUjVewzx_Xfm7vKmHEb3I X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 24 Mar 2014 18:32:32 -0000 --_9987d60d-779a-4a18-9ec1-bb168775fb77_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All=2C Is the BFD poll sequence tied to a particular BFD session state? In other w= ords=2C can a node start the poll sequence in DOWN or INIT states? BR=2C Ashesh = --_9987d60d-779a-4a18-9ec1-bb168775fb77_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All=2C

Is the BFD poll= sequence tied to a particular BFD session state? In other words=2C can a n= ode start the poll sequence in DOWN or INIT states?

BR=2C
Ashesh<= br>
= --_9987d60d-779a-4a18-9ec1-bb168775fb77_-- From nobody Mon Mar 24 11:38:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80811A0298 for ; Mon, 24 Mar 2014 11:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNgT5dvCq9FB for ; Mon, 24 Mar 2014 11:38:26 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0D1A02AE for ; Mon, 24 Mar 2014 11:38:25 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id w7so3935326lbi.2 for ; Mon, 24 Mar 2014 11:38:24 -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=tlJNs30wrAtRy4zdbTC12A8hYxBd8ZWt51UjPMkH0mo=; b=SEJLsKDx3pF2pSQlqgYpRt7ZMq3gT0ZHvVminAD3SQyIwysHqxRENOcGx3+wca6rpW pB4n77o4AbdQ7ls5J9wNZWwSBjGHHh3j0fjRFBWVjY10r90315Xl87z5TIkuPn+RIuT0 rh1Qv+bPGyiEqjvGi8Z3hyha6t0ymBXV78ZZsS1fKYYbpokIp7m3o1TDP2aajPiu9Leq jrDKCMLeOoqSrDjNDQjLP2zQGyhXRTte+m8NyD/hXZcrF8gohJmQdvKLPDmetoZBz81m AN/RbbAkLh+zEipTghCjdTAYlAh32tVj7tCo72t+1RJZZ9ldgzgvDhI8nQc357xu9sF1 Omfw== MIME-Version: 1.0 X-Received: by 10.112.131.34 with SMTP id oj2mr2172560lbb.43.1395686304262; Mon, 24 Mar 2014 11:38:24 -0700 (PDT) Received: by 10.114.2.110 with HTTP; Mon, 24 Mar 2014 11:38:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Mar 2014 20:38:24 +0200 Message-ID: Subject: Re: Poll Sequence in BFD From: Binny Jeshan To: Ashesh Mishra Content-Type: multipart/alternative; boundary=047d7b343ba6622f3a04f55e8ad6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ct0LsM5s9c4rSt4lGzSOGvUhxMs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 24 Mar 2014 18:38:28 -0000 --047d7b343ba6622f3a04f55e8ad6 Content-Type: text/plain; charset=ISO-8859-1 i dont think in INIT state u do a poll. Poll can be more relevant in UP / DOWN states. However be ready to take a poll sequence in any state where you are in, be flexible with that. Regards, Binny Aricent, India On 24 March 2014 20:32, Ashesh Mishra wrote: > Hi All, > > Is the BFD poll sequence tied to a particular BFD session state? In other > words, can a node start the poll sequence in DOWN or INIT states? > > BR, > Ashesh > --047d7b343ba6622f3a04f55e8ad6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
i dont think in INIT state u do a poll. Poll can be more r= elevant in UP / DOWN states.=A0

However be ready to take= a poll sequence in any state where you are in, be flexible with that.

Regards,
Binny

Arice= nt, India


On 24 March 2014 20:32, Ashesh Mishra <mishra.ashesh@outlo= ok.com> wrote:
Hi All,

Is the BFD poll sequence tied to a par= ticular BFD session state? In other words, can a node start the poll sequen= ce in DOWN or INIT states?

BR,
Ashesh

--047d7b343ba6622f3a04f55e8ad6-- From nobody Tue Mar 25 06:01:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFAC1A0110 for ; Tue, 25 Mar 2014 06:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dz0qjrXjSK3 for ; Tue, 25 Mar 2014 06:00:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4707A1A0115 for ; Tue, 25 Mar 2014 06:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=908; q=dns/txt; s=iport; t=1395752440; x=1396962040; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7YzkG4kMnrj8fz1IOrUORTcFMoZH6Tes0mMaQq/NW6M=; b=NpYlVwQ7Jl7BUcbE24ea3OU0ps9IyqcRgmU+Fls2q1CbAemzAtnLWa7s bsW4ekRLDCvUY+4B6v+6gLJ8PkMV9RlkA0j5SSEeaDZ2J3nWOfq4vbAaO HAuUlpmzsNLIzY6+XSA3RRdn/RYEPvWqnQS7BudSqpQj6CZOZMDY3NnyN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAFx9MVOtJV2b/2dsb2JhbABZgmUhO1e7OIc1gSIWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAcBAQUDAgQTCAGHcAEMzncXjj04BoMegRQEqn+DLoIr X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208";a="312725030" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 25 Mar 2014 13:00:40 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2PD0eXr010130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Mar 2014 13:00:40 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 08:00:39 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: FW: [PWE3] Slides from Adrian's talk at the MPLS WG meeting Thread-Topic: [PWE3] Slides from Adrian's talk at the MPLS WG meeting Thread-Index: AQHPR6OIc/+gu1yQEE+f2f/l7td3bJrxwphQ Date: Tue, 25 Mar 2014 13:00:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bS2Vb4XU_xf_zVeRa5plAFOE1q4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2014 13:00:43 -0000 In case you didn't get a chance to attend/read ... great set of slides. -Nobo > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis > Sent: Monday, March 24, 2014 4:56 PM > To: pwe3@ietf.org > Subject: [PWE3] Slides from Adrian's talk at the MPLS WG meeting >=20 > PWE3ers, >=20 > Adrian gave a talk at the MPLS WG meeting on how to write quality drafts > and make the path to an RFC go much easier. While a bit of it is centric = to > the MPLS WG, much also pertains to work in our WG as well. You should > read his slides, especially if you didn't get a chance to see his talk in= the > MPLS WG. >=20 > http://www.ietf.org/proceedings/89/slides/slides-89-mpls-15.pptx >=20 > Cheers, > Andy >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Sat Mar 29 12:29:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E981A0718 for ; Sat, 29 Mar 2014 12:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD9eJQc0SIt4 for ; Sat, 29 Mar 2014 12:29:11 -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 D06461A06B8 for ; Sat, 29 Mar 2014 12:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5106; q=dns/txt; s=iport; t=1396121348; x=1397330948; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=KlmNFmmzKz0BByaxGYhdGrpeHEwHDmaomf4sUyVmN/c=; b=G4L8+3fEdjdjr2aAgV54fFHaissF7UKOdr0skRZjLHnVsXRPZSrcDRAP +AZl5asHUB32xQkTEX9kYDZ3dJwQAZN0sxkcYe7jzKPh7NXLFl83/t0to 7ZbZBMkFmN2Pzqk1UpTRU24/2h/lgP0Q6gkp7YxT/85LHNt03DfPY+Y9E 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOEdN1OtJXG+/2dsb2JhbABPAQmCZSGBEsMNgRMWdIInAQQ6MSABKhRCJgEEEQqHcQGfX7FkF44jASqDXIEUBKsDgzBBgWo X-IronPort-AV: E=Sophos;i="4.97,757,1389744000"; d="scan'208";a="313823597" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 29 Mar 2014 19:29:08 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2TJT8HH026883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 29 Mar 2014 19:29:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Sat, 29 Mar 2014 14:29:07 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Comments on draft-ietf-bfd-multipoint Thread-Topic: Comments on draft-ietf-bfd-multipoint Thread-Index: Ac9LX4T1mkqXHr1zQeKTN9JZigKYEA== Date: Sat, 29 Mar 2014 19:29:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Bkohxh9WYc-X__DUDMsf8IsfqOI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Mar 2014 19:29:13 -0000 Hi BFDers, [chair hat on] We are nearing another milestone: BFD multipoint draft. Jun 2014=20 Submit the the document on BFD point-to-multipoint support to the IESG to b= e considered as a Proposed Standard I'd encourage everyone to read draft-ietf-bfd-multipoint, provide comments = to help progress this draft. [chair hat off] I have just re-read draft-ietf-bfd-multipoint draft, and have few comments. Although I'm not quite sure who these comments are directed to, as I guess = authors may not have cycles to pick this up. Anyways ... 1. Request to add clarity to procedures describing demultiplexing of BFD co= ntrol packets. Section 4.16.2: [old] If bfd.SessionType is MulticastHead Select a session based on the source address and the value of Your Discriminator. If no session is found, a new session of type MultipointClient MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. If bfd.SessionType is not MulticastClient, the packet MUST be discarded. [new] If bfd.SessionType is MulticastHead Find a MultipointClient session grouped to this MulticastHead session, based on the source address and the value of Your Discriminator. If a session is found and is n= ot MulticastClient, the packet MUST be discarded. If no sessio= n is found, a new session of type MultipointClient MAY be created, or the packet MAY be discarded. This choice is out= side the scope of this specification. 2. Comment on the snippet from above (1). Because MultipointClient demultip= lexing does not include received My Discriminator, assumption is that there= is only one receiver of this multicast tree per source address. Is this a = fair assumption for all technologies out there? I'm not a multicast expert,= I figured it's safer to raise this point and ask. 3. Request to add a consideration in the "Security Consideration" section. RFC5880 does also states "... a session MAY be created" upon reception of B= FD control packets. However, this draft places more emphasis (than RFC5880)= on the dynamic creation of sessions. For example: Section 4.7: Sessions on the tail MAY be established dynamically, based on the receipt of a Multipoint BFD Control packet from the head, and are of type MultipointTail. Tail sessions always take the Passive role. It would be beneficial to add some suggestions in the "Security Considerati= on" section to allow implementations to be more protective. What I mean is ... MultipointTail sessions are dynamically created. If I had a way of getting = around GTSM & Authentication (or lack of) and was aware of a source address= that will pass the "check", then I could DoS this system with range of My = Discriminator values to leaves, which will cause many instances of Multipoi= ntTail sessions to get created. Draft does say [create or discard] choice i= s outside the scope (in 4.16.2). But given the dynamic nature of session cr= eation, it would be beneficial to highlight this point and provide suggesti= ons in the "Security Consideration". If we re-word section 4.8 slightly, we can actually strengthen this a bit. [new] The head sends Multipoint BFD Control packets over the MultipointHead session with My Discr set to a value bound to the multipoint path, and with Your Discr set to zero. The tails MUST demultiplex these packets based on a combination of the source address and My Discr, which together uniquely identify the head and the multipoint path. [old] The head sends Multipoint BFD Control packets over the MultipointHead session with My Discr set to a value bound to the multipoint path, and with Your Discr set to zero. The tails MUST demultiplex these packets based on a combination of the source address, My Discriminator and the identity of the multicast tree which BFD Control packet was received from. Together they uniquely identify the head and the multipoint path. If BFD Control packet did not arrive on a multicast tree, then the mechanisms described in this document SHOULD NOT be used. This change will require that any attack against leaves be in-band (or at l= east appear that way to the leaves). Similar can happen (and easier) with dynamic creation of MultipointClient s= essions on the root. Once attacker obtains MultipointHead address and discr= iminator, range of IP addresses can be used to DoS the root (unicast), caus= ing large number of MultipointClient sessions to get created. Thus I see value in writing something in the "Security Consideration". One = thing which could be mentioned is that, for MultipointClient, suggest that = MultipointClient MAY be created if tail polling was done "recently" ... and= define "recently". -Nobo From nobody Mon Mar 31 14:32:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36B81A6F66 for ; Mon, 31 Mar 2014 14:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THOOcH39b3BG for ; Mon, 31 Mar 2014 14:32:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D90C51A0789 for ; Mon, 31 Mar 2014 14:32:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A57A4C246; Mon, 31 Mar 2014 17:32:38 -0400 (EDT) Date: Mon, 31 Mar 2014 17:32:38 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: New editor for draft-ietf-bfd-multipoint Message-ID: <20140331213238.GE28363@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/i8_DPLPME8YeL6oEx_WYXTarF_I X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 31 Mar 2014 21:32:43 -0000 As the Working Group strives to empty our queue (partially to make way for new work!), we need a more active editor for the BFD Multipoint draft, draft-ietf-bfd-multipoint. Santosh PK has agreed to take up the work of being the primary document editor to drive the document to RFC status. Dave Katz and Dave Ward will continue to be listed as the document's authors. To date, I've heard of two implementations of the feature, although without the active tail feature. We'll be nudging those implementors to review the draft's text and help us make sure specification meets the reality check of the specification. In the mean time, please review the published draft and submit your technical and language edits. Our goal is to prepare the document for preliminary Working Group Last Call for the July IETF timeframe. If there are any substantial issues, we'll try to get them resolved and targeta second last call prior to the November IETF. -- Jeff and Nobo