IETF Logo Mail Archive

Re: [Lsr] 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 16:52 UTC

Return-Path: <gunter.van_de_velde@nokia.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86E0130F25; Tue, 7 Aug 2018 09:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 V9tkf6oaIjDD; Tue, 7 Aug 2018 09:52:31 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40134.outbound.protection.outlook.com [40.107.4.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CB712777C; Tue, 7 Aug 2018 09:52:30 -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=anxSQLFk3wdf9NtbocuxK6BI4hgvspRnet3KhAQI2QE=; b=MPmyn7psLU0eGek3jfPVZlonBSVk5P+P+tvK7FFThMlxJ2MVU6kD/rG23ctDOWPBjNXsjLA1dPPsBy9KZy3PQYGiSJGV/gq1BdHfn+EmRC9v01+e7tuaLXAsUeVFGhIITlKVq1Vbr1igXiKpRYMTFS8DM7QJqogAxbzhbwABBlo=
Received: from AM5PR0701MB1729.eurprd07.prod.outlook.com (10.167.215.136) by AM5PR0701MB2785.eurprd07.prod.outlook.com (10.173.94.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.10; Tue, 7 Aug 2018 16:52:28 +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 16:52:28 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, 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+uXXuoqthRMlgAK6gDwAAIYoUA=
Date: Tue, 07 Aug 2018 16:52:27 +0000
Message-ID: <AM5PR0701MB17298EF306FB6029779F39C4E0270@AM5PR0701MB1729.eurprd07.prod.outlook.com>
References: <AM5PR0701MB1729E94EB59F656676E85833E0270@AM5PR0701MB1729.eurprd07.prod.outlook.com> <8604646bebc4452e9072c91f7db5cfbd@XCH-ALN-001.cisco.com>
In-Reply-To: <8604646bebc4452e9072c91f7db5cfbd@XCH-ALN-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com;
x-originating-ip: [2a02:a03f:4e49:7500:417a:4d30:2f01:37a3]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2785; 6:T4W5McS+TzQLR4C5ADV2eXNZSKrfxPZ7cbxpIH2wn4GpQgPc/6bYkd/g0Wh0HQxSc/trA8Y+hwBTodwEtQrDTlUJ+s5ewnUFrsBcHRsX00iVwE0Yv07qR9C8MuP1SLI9gD183wUo/wQYWeyeJUWkKGCroAHNg0Yejf1bqIgaI3zVgVti49MTu2OR+ADDmoAb8bxvN12WM0codVigWLrE1kPuuHpvsPXvF18mpew4HGjvf+EIJtVeb8TlE+0URy6KEfoubZqrhGQtjupmCYSztkeh6LX8e0phAOUAfqgrkV1BnDhbu/eWqnafW9+l9S6uPrD2FHNmLLWc6T01RZ+3ymS8FczAtZobtJa8lhSa/G7dyOFWOsZUwXgz/lcfD2mJp4ZXepbllrT33Fx2SwR+WPzheHwF/RIzsp1M1tEHA8mt5cf0/Ijonob32UWlsrgEuloSiat9C5hLHPutLgqdlw==; 5:FZtngbtkCdC4sL/sBImplnr0m1nf9mbp/xC009QXhnrZuKu6nPj7d5p7YIdhUJSkduvIr26VT5Ydw6mKm4yYsn3LBM5THXuWAYS2K4oUvsL3DU2smfv3L5lpAxo00kKU464KbXpb9NeE4SOCcDslBJijMJr8FvxB93Hhnt865mA=; 7:FFzg8K/Yr0t5BwVCT8bX/n8CovNxSZT/636lA4G6lF8Hq/SGBU+hxi8ED+cDiI/m/JHqiCt3o85vCwOi+Tin97HXBXDRwqyFOsy4XcdK5M7NQE4ZVNWyqKbSQAL/+qojCaJki3bDtZLffmpsnrlJkUS9cvoY17ziMBMKrZbZcMLjkkUoLg+vBqr3EmjySB22t55mtayD2MmotMrB7NB1SDu/8Nl6ersLI8AJUF722Ax0UAmnfQnQEqqAdSG9X6lK
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(136003)(396003)(346002)(366004)(39860400002)(376002)(199004)(189003)(2906002)(7696005)(39060400002)(476003)(2900100001)(11346002)(6436002)(53936002)(446003)(4326008)(102836004)(229853002)(5250100002)(606006)(99286004)(53546011)(55016002)(110136005)(107886003)(486006)(76176011)(6306002)(54896002)(2501003)(33656002)(9686003)(6246003)(6506007)(7736002)(74316002)(236005)(316002)(81156014)(68736007)(8936002)(106356001)(105586002)(5660300001)(790700001)(256004)(81166006)(8676002)(217873002)(97736004)(186003)(86362001)(6116002)(14444005)(46003)(25786009)(14454004)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2785; H:AM5PR0701MB1729.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-office365-filtering-correlation-id: 35f5f52b-baa9-457b-84f6-08d5fc8628bd
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM5PR0701MB2785;
x-ms-traffictypediagnostic: AM5PR0701MB2785:
x-microsoft-antispam-prvs: <AM5PR0701MB2785ED0195CA3E1E73159A05E0270@AM5PR0701MB2785.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(82608151540597)(85827821059158)(109105607167333)(195916259791689)(95692535739014)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2785; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2785;
x-forefront-prvs: 0757EEBDCA
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: J+sTlgus6rYbzVTmd/RpM2ZDQXBz/K1tZGWtOE3J+TQ2gHBT9snsg+q3jJaLrxFE8hP/zLDYWnadpeTxKSl7lUkQLdoxsfsU5jDcXpLng1VfDKXWUBetHQu4rAIse5J9ugvp8VMvHdwrazpNayj0yK/5oSvmLZicQunpfTyjvV/NQqIyCiUOmcdycO8TkTsIugu4yasfjP5KklF6Js5vRS+bi9hRjHXccgX8YIy0B9MXqWoOzu4oHYZyFL1vaxQv8JLnz4Szacmt+i1BuM2KhC1ueR8+Da1sN6ibjn1FEfmwS62ErhHYWiZf7WmZRFHlgQWGoj8bRG2j5eCrxt8ZVeb57xWfDQtx6/JecatWoVtRO+gq/peiRmphagTvAFgWdQALpOTTjw8ymzNrr+4r4g==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB17298EF306FB6029779F39C4E0270AM5PR0701MB1729_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35f5f52b-baa9-457b-84f6-08d5fc8628bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2018 16:52:28.1328 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2785
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/l1xR6GPJ_IbwTkXORs6zj_iWAIg>
Subject: Re: [Lsr] What is the motivation for RFC8401 to have a strict "MUST NOT be set" for R-Flag?
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2018 16:52:35 -0000

Hi Les, thanks for this confirmation.

G/

From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Sent: Tuesday, August 7, 2018 17:57
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>; bier@ietf.org; Tony Przygienda <tonysietf@gmail.com>; lsr@ietf.org
Cc: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
Subject: RE: What is the motivation for RFC8401 to have a strict "MUST NOT be set" for R-Flag?

Gunter -

In early versions of the draft we did not support inter-area, so we specified that R bit MUST be 0.
Then in V6 of the draft we allowed for inter-area support and the text relating to R-bit was removed.

However, somehow the text regarding R-bit ended up being put back in V9 of the draft. I don't think there was any reason for this - probably just a cut and paste error.

At this point I think you will need to file an Errata.

Sigh...

    Les


From: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>
Sent: Tuesday, August 07, 2018 3:40 AM
To: bier@ietf.org<mailto:bier@ietf.org>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>>; lsr@ietf.org<mailto:lsr@ietf.org>
Cc: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>
Subject: What is the motivation for RFC8401 to have a strict "MUST NOT be set" for R-Flag?

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