RE: Questions related to single-hop IP BFD over IPv6

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 25 May 2017 14:41 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA941296CD for <rtg-bfd@ietfa.amsl.com>; Thu, 25 May 2017 07:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level:
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
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 nzzsBVwzdXCZ for <rtg-bfd@ietfa.amsl.com>; Thu, 25 May 2017 07:41:40 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1377C1200FC for <rtg-bfd@ietf.org>; Thu, 25 May 2017 07:41:39 -0700 (PDT)
Received: from [85.158.138.179] by server-9.bemta-3.messagelabs.com id 0E/78-26749-22DE6295; Thu, 25 May 2017 14:41:38 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSaUgUYRjH951jdxLHxlXzadHArSxMRUtEgkI K0+j80IGh1FiTu7SH7Ky1QaAphWlWUFZauZuKVhrYZnZYeX3RtMu01FIqK2zt0syyy3b21bJv v/f9/ec5hpchlS1yFSNYzILJwOvUcjcqIiA6MSTgfWB82OmsiChbbj0VVVc5gqI+/6xG0WTcs R+X6LiSklEi7klGh2ItuYnWGpKMli205kSpnUx5cA5ZalrtVDoqPo6ykRtDcftJcFxtlEsHJX eMgOyuUgIfniPI/HHPGZvCyLlFYC/vkUvszS2Hh/ajri9ILpeAs/XnaUl4SSFHE41Di6GxLkO BeT60nBtyFaK42fCydszZgWFYLgGsrd7SNeKmwdc7FYTEJOcL3a+sLgaOg5Kb90nMPvC27zct 9UXcYQQ3yzMoLALgZO9pBWZ/aLPmuHYD7iAJZU1F4yIIBpvfkFJj4FZBR7cK40yo6k/EiRwEt SWxmHdAde+78Rn2wKH67wpcsoUGxwPbuPCDk0MfCSwaaLiYfoPCP0IFPe0HEGY/6H92i8abGe Dx6DdXhuU8oTn/FXUEBRZMWrpgUqxgUgzfB4OtZkiOeR6Unh0gJ7i1ro+YfG9DigtojiiYdgq mkMjQJJM2WWPW81pdSHjYglC9IIp8sqDjk8TQrUa9HTkfVppMhq6h9v1LG9B0hlD7sL5nAuOV HknGbbs1vKjZbErVCWID8mMYNbBT3zmdp0lIFizbtTrn65zQwLirvVkfSbNiCq8XtclY3UEhj K2qaphQUgajQVD5sjOkECeFNKmGvyUm3ngb8ld5sUgmkyndUwSTXmv+3zuQL4PUXuybAWcVd6 3B/LeTwzkE4RwipmemNISZ/6dU6ag6rah+BTE264tHWmX+5bmpmatvk427P1GBzPV4x+eKXcV 1589cedu/d3B9amTWKeVI3uvC/kXGXD52bHDfWPqa6OEu+YZNS36t3FhmvFtaNtJXOPgh2K3z 1F5rm+VoZ1D46ysxefAoZmcsSzxNWJhQ5pNPiS86131cs2wG0yW33RpWU6KGDw8iTSL/B3zEO lTeAwAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-12.tower-169.messagelabs.com!1495723294!99837447!1
X-Originating-IP: [52.33.64.93]
X-StarScan-Received:
X-StarScan-Version: 9.4.12; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 27755 invoked from network); 25 May 2017 14:41:36 -0000
Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-12.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 25 May 2017 14:41:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZsDY0kD2P0qrH9gKQ1MRkfNXAKzeW/sOWQq3K2TUCDk=; b=kufCW35cWiQ9N98bx+MKfrevsWZMfK3YBcHeMHe2vZhq2lxjkMv73Ra6f4F7WprM02BoGelAnPlzl/AdlswfFc5XtMukpaYbgWRh1Y6MbGydYmDO9dVIswptPasW3CTPgo27jWIIY+U1zGGD+oR/74GTA4BiPcc566V4k8vR7Qo=
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1586.eurprd03.prod.outlook.com (10.165.243.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Thu, 25 May 2017 14:41:26 +0000
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::21f9:af8d:c7ff:3e13]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::21f9:af8d:c7ff:3e13%14]) with mapi id 15.01.1101.022; Thu, 25 May 2017 14:41:26 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "dkatz@juniper.net" <dkatz@juniper.net>, David Ward <dward@cisco.com>
CC: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Alexander Ferdman <Alexander.Ferdman@ecitele.com>, Shigang Wang <Shigang.Wang@ecitele.com>, Natalie Rogozovsky <Natalie.Rogozovsky@ecitele.com>, James Lian <James.Lian@ecitele.com>, BFD WG <rtg-bfd@ietf.org>
Subject: RE: Questions related to single-hop IP BFD over IPv6
Thread-Topic: Questions related to single-hop IP BFD over IPv6
Thread-Index: AdLP27i72+NIRcUiTFm1+2kgKRo89QFiQ8Rw
Date: Thu, 25 May 2017 14:41:26 +0000
Message-ID: <AM4PR03MB1713FB65AD7CD28E71556B979DFF0@AM4PR03MB1713.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1586; 7:OEusQP2x720gzTGS6+jSMRO1c3kf/cKkWXsVPeItTa3OehESfsiJymiMO8REM2UCkuVRtqB9P5rNYDpXTs2uD1m8Saz+INr39sKOf3hLmddeAv3t+8T2hxlVZiNB33Y+Av+0Y91BQvjszIfg+LRqzCk5NouzWcU1vyBWc4N5X6DCVaD6Yi+a1uH6tUUJ5bSXk6ZzzxgFelHM8aIGS3IpfsTSRaPZ+5xgoJNw0dJHOqRVsdISeLFx8FzZ2Cf/ZzNHeDqfB2sjGSLHHd/dJgbI6ajftTCyCfgxqpJD6rgNk40ovp8Qe/AfDYf38n86uvS4hKePHfJljAr/vFMKzPa+HA==
x-ms-traffictypediagnostic: AM4PR03MB1586:
x-ms-office365-filtering-correlation-id: 525985f1-8f21-44ac-541d-08d4a37c1f5c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM4PR03MB1586;
x-microsoft-antispam-prvs: <AM4PR03MB1586062D82C9C40840E72E799DFF0@AM4PR03MB1586.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(72170088055959)(138986009662008)(95692535739014)(21748063052155)(279101305709854);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700054)(100105000095)(100000701054)(100105300095)(100000702054)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703054)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(100000704054)(100105200095)(100000705054)(100105500095); SRVR:AM4PR03MB1586; BCL:0; PCL:0; RULEID:(100000800054)(100110000095)(100000801054)(100110300095)(100000802054)(100110100095)(100000803054)(100110400095)(100000804054)(100110200095)(100000805047)(100110500095); SRVR:AM4PR03MB1586;
x-forefront-prvs: 0318501FAE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39450400003)(39410400002)(39850400002)(39840400002)(39860400002)(252514010)(377454003)(790700001)(102836003)(6116002)(3846002)(99286003)(6306002)(9686003)(54896002)(55016002)(53936002)(7736002)(236005)(478600001)(413944005)(5250100002)(2501003)(72206003)(53546009)(66066001)(38730400002)(6246003)(25786009)(189998001)(86362001)(50986999)(8936002)(3280700002)(3660700001)(2900100001)(81166006)(8676002)(54356999)(4326008)(8666007)(229853002)(6436002)(5660300001)(606005)(2906002)(6506006)(74316002)(33656002)(7696004)(7906003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1586; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713FB65AD7CD28E71556B979DFF0AM4PR03MB1713eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2017 14:41:26.1107 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1586
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/k7eZdSiNAzAWCyC-46xCwidujEY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 14:41:42 -0000

Dear colleagues,
This is a gentle reminder about questions I've asked exactly 1 week ago.
Your help would be highly appreciated.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Alexander Vainshtein
Sent: Thursday, May 18, 2017 5:14 PM
To: 'dkatz@juniper.net'; <dkatz@juniper.net>;; David Ward <dward@cisco.com>;
Cc: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>;; Alexander Ferdman <Alexander.Ferdman@ecitele.com>;; Shigang Wang <Shigang.Wang@ecitele.com>;; Natalie Rogozovsky (Natalie.Rogozovsky@ecitele.com) <Natalie.Rogozovsky@ecitele.com>;; James Lian <James.Lian@ecitele.com>;; BFD WG <rtg-bfd@ietf.org>;
Subject: Questions related to single-hop IP BFD over IPv6

Dear colleagues,
I have several questions dealing with single-hop IP BFD sessions over IPv6. So far I have failed to find clear answers to these questions in RFC 5881<https://tools.ietf.org/html/rfc5881>;.


1.       Is it possible to use link-local source and destination IPv6 addresses in encapsulation of single-hop IP BFD Control packets? For the reference:

a.       Section 4 of RFC 5881 explicitly states that link-local addresses SHOULD NOT be used in encapsulation of BFD Echo packets, but it does not say anything about BFD Control packets

b.      OSPFv3 for IPv6 always uses link-local IPv6 addresses as the Next Hop addresses of the routes it computes (see RFC 5340<https://tools.ietf.org/html/rfc5340>;, Section 4.8.2). Therefore it looks reasonable to me to use single-hop IPv6 BFD sessions with link-local addresses at least for monitoring OSPFv3 adjacencies

2.       Section 3 of RFC 5881 states that "there will be only a single BFD session between  two systems over a given interface (logical or physical) for a particular protocol". I would like to understand how this requirement can be addressed in the following scenario:

a.       Let us assume that the answer to the question 1 above is positive.

b.      Let's further assume that:

                                                               i.      Router A and Router B are connected across a single IPv6 hop (an IPv6 link)

                                                             ii.      A single-hop IPv6 BFD session using link-local addresses of the corresponding interfaces has been successfully established

                                                            iii.      Globally unique IPv6 addresses have been configured on the interfaces terminating this link in Router A and Router B and have successfully passed the DAD check, i.e., these addresses are assigned and preferred addresses in the terminology of RFC 4862<https://tools.ietf.org/html/rfc4862>

                                                           iv.      The user (or some application) now tries to set up a single-hop IPv6 BFD session bound to the same interfaces but using globally unique IPv6 addresses assigned to these interfaces

c.       Should, under the assumptions above,  the implementation prevent formation of an additional single-hop IPv6 BFD session between A and B running across the same link but using assigned globally unique IPv6 addresses of the corresponding interfaces? If yes, how can this be achieved?

d.      Similar to above, but:

                                                               i.      The interfaces connecting Router A and Router B have been assigned with multiple globally unique IPv6 addresses

                                                             ii.      A single-hop IPv6 BFD session using one pair of assigned IP addresses of these interfaces has been successfully established

                                                            iii.      Should the implementation prevent formation of an additional single-hop IPv6 BFD session between A and B running on the same link but using a different pair of assigned globally unique IP addresses? If yes, how can this be achieved?

Your inputs would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>


___________________________________________________________________________

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