IETF Logo Mail Archive

[Bier] What is the motivation for RFC8401 to have a strict "MUST NOT be set" for R-Flag?

"Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com> Tue, 07 August 2018 10:39 UTC

Return-Path: <gunter.van_de_velde@nokia.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56D3120049; Tue, 7 Aug 2018 03:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_HIGH=-0.01, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 NHCzsErThTku; Tue, 7 Aug 2018 03:39:56 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10131.outbound.protection.outlook.com [40.107.1.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A6E130FA9; Tue, 7 Aug 2018 03:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dLnE5wLwAZ+bzuvNIEZFbq2+bFI9LV1JocECCsAlByg=; b=KF3ZCBhQh20iEkX+YxnnyapyILAKQe8O1X2mppzeM84HjP6kIfG4LLmPzGciqm4q01TsfGvKIYkWiRjkT15SLv3NCRensZ394Kq34So/V1pw7z/WuzbSv4B1K2krXuMaauGOU7n3EM7b2PCKRTQx2vUF4W4ruccusKtfrMFSTH8=
Received: from AM5PR0701MB1729.eurprd07.prod.outlook.com (10.167.215.136) by AM5PR0701MB2739.eurprd07.prod.outlook.com (10.173.93.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.16; Tue, 7 Aug 2018 10:39:52 +0000
Received: from AM5PR0701MB1729.eurprd07.prod.outlook.com ([fe80::3ca0:9fbf:f2d:64d8]) by AM5PR0701MB1729.eurprd07.prod.outlook.com ([fe80::3ca0:9fbf:f2d:64d8%5]) with mapi id 15.20.1038.013; Tue, 7 Aug 2018 10:39:51 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: "bier@ietf.org" <bier@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Tony Przygienda <tonysietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
CC: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>
Thread-Topic: What is the motivation for RFC8401 to have a strict "MUST NOT be set" for R-Flag?
Thread-Index: AdQuOt85jH56m2TUR+uXXuoqthRMlg==
Date: Tue, 07 Aug 2018 10:39:51 +0000
Message-ID: <AM5PR0701MB1729E94EB59F656676E85833E0270@AM5PR0701MB1729.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2a02:1810:4d67:a00:d03f:fd4:54e2:f5a2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2739; 6:/LcIzhxwK+FFa3gNAjQfyxmJHmt3LIpmfjUM57p/o1sPZobuUM4NeZn0Aa2fIG1DbTemrQaCixRjsDLvgfkvwhz8a6qoNiNIH8BAdMM4QqsSWZR2qIvT58lDLcUMMsQWEuWcFp40vJg6KNGsFdCbKOIxJT5gWWDehjSDtxJa9V3J1lE51UboOMD9ueagOdUdUzIM8xuNJf5rodEGONB3d22YHn/nsy/roaO800f/8Idc81S2y4Ben3+eAmbX7tbtdzo8hIT+2qTn4Hq5+tcSYbjrof7JdyaUn+z/iS4CsBFD9fVhjBStPeeC2yj8EgQLXdT46Jg4e68e0Ch5gOMTxUnZLlSlEw4JnUvm0IEfsGWa4rxNs77GDS/J1HsPyiexR0odaxal1GxKeTGoB+r3FuddWz6KWPV2ZPbxydknimanHIyvkdJUc19FrJty9NhuuZa6DvFaU/pG0bt+657ADg==; 5:qp38DRc3AkHu58Tsv5LlKgvIuxs7j0qLYUuMjoS/X8+dgJFL/wQA8LSfY3KF1zhp2cylYOn7+61F07KaTeQ7H2yz1VjBBQZQa2mEyC3xrVN1s7s37rQ+CABenIRz0SqsjIyk02EryP+tLBl8+d1m3NkqK50QXkwIq1wO9IKPNWU=; 7:pHiE3pVovI7QuW5ORZlMV/0tD9x55aLImT1IE6DCnekW4gkk1vZNmGzKjO51/o926ufl+ZYUwxyWVtOJSd4E/nCdcgyA8Nv4LW4mbJFwpAvBLMDAG9FdPHDsaM7UKgeZ9V+zdPNmcTXA5/SJ5t3VDLR2I1bVAU5HC5Hb+OgfEJv87SJ/J2P0tuOEw18afNxXLQRVrS256gKTkEwYyBrkPSyDls+IKkXbbGQXOOwkoBjL9MaU5dEaKv1SRpnPd5Oo
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(366004)(136003)(346002)(189003)(199004)(105586002)(6116002)(790700001)(478600001)(2906002)(106356001)(68736007)(8936002)(33656002)(14454004)(5250100002)(606006)(2501003)(25786009)(7736002)(99286004)(81166006)(81156014)(316002)(5660300001)(110136005)(4326008)(46003)(256004)(186003)(476003)(217873002)(102836004)(6506007)(86362001)(97736004)(74316002)(236005)(6436002)(55016002)(54896002)(9686003)(486006)(53936002)(6306002)(107886003)(2900100001)(8676002)(39060400002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2739; H:AM5PR0701MB1729.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-office365-filtering-correlation-id: 61554c78-2d2b-4a50-ffee-08d5fc521b4b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:AM5PR0701MB2739;
x-ms-traffictypediagnostic: AM5PR0701MB2739:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com;
x-microsoft-antispam-prvs: <AM5PR0701MB273998CB2BCD0304E32853ECE0270@AM5PR0701MB2739.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(823301020)(3231311)(11241501184)(806099)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2739; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2739;
x-forefront-prvs: 0757EEBDCA
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: EQSJednyNm4DX3HkjcdHld17//R9l4ElulL9KTCCHK5JeiP/z97MigyJ1iXNIgRbe/vxXAAAs/vUOi76hCWsJWDu0ssk1tEvr9LSAiiQuxxJYGn8oLEaMNt4R3plQEOxNNhI++2z6F6KUQhKJGz532B505KcIaNOa8bU4lSKdX28v/xHe6zvNRwBrtNb+1FfaiPl/GBCNNRwX+T7kWLWyiBC3OkqN3PpbNKobXwotVW/9KVIOYY/DgUMaOOP7MAKrsX2OOAg7vxzNKrdn72NyA2z6eni5jW/faOQibUGX0yA3+Vn0Cp/NBqbYEqwF8PtjLXLynzKOnpUqEJXBIACxW98Qqm3ijfiJAkpujQnKGtvJ/I3LNcmnAQryxumM1V3BPg8QrfbuLN0g0Aktjizag==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB1729E94EB59F656676E85833E0270AM5PR0701MB1729_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61554c78-2d2b-4a50-ffee-08d5fc521b4b
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2018 10:39:51.7175 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2739
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/yqG4GmDg5q11ZCFk7OHYX_DSJtU>
Subject: [Bier] What is the motivation for RFC8401 to have a strict "MUST NOT be set" for R-Flag?
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2018 10:39:59 -0000

Folks,

When having desire to do BIER between ISIS L1/L2 domains then there is something I do not understand.

In RFC8401 I see:
4.2<https://tools.ietf.org/html/rfc8401#section-4.2>.  Advertising BIER Information

   BIER information advertisements are associated with a new sub-TLV in

   the extended reachability TLVs.  BIER information is always

   associated with a host prefix, which MUST be a node address for the

   advertising node.  If this is not the case, the advertisement MUST be

   ignored.  Therefore, the following restrictions apply:



   o  Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6

      prefix.



   o  When the Prefix Attributes Flags sub-TLV [RFC7794<https://tools.ietf.org/html/rfc7794>] is present, the

      N flag MUST be set and the R flag MUST NOT be set.



   o  BIER sub-TLVs MUST be included when a prefix reachability

      advertisement is leaked between levels.

In RFC7794 I find:


   R-Flag:  Re-advertisement Flag (Bit 1)

      Set when the prefix has been leaked from one level to another

      (upwards or downwards).

The issue that is unclear to me:


  *   If I leak a (node-)prefix between L1/L2 then I MUST set the R-flag (according RFC7794), but then this seem to contradict the strict MUST NOT from RFC8401.

What logic am I misunderstanding? Why is the motivation in RFC8401 regarding the strict "MUST NOT be set" requirement for the R-Flag?

Brgds,
G/

v2.23.0 | Report a Bug | By Email