[Idr] BGP-LS TLV Error Conditions
Alvaro Retana <aretana.ietf@gmail.com> Wed, 30 January 2019 21:44 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA74D13132B for <idr@ietfa.amsl.com>; Wed, 30 Jan 2019 13:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EbUemreKqegs for <idr@ietfa.amsl.com>; Wed, 30 Jan 2019 13:44:49 -0800 (PST)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243D6131338 for <idr@ietf.org>; Wed, 30 Jan 2019 13:44:49 -0800 (PST)
Received: by mail-oi1-x233.google.com with SMTP id m6so941602oig.11 for <idr@ietf.org>; Wed, 30 Jan 2019 13:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=z7Jk5kZUgCJZ/VqKyob9Qa1g3SkLh/K7wnRkEtrITuc=; b=cS7yVeigv+H2AtQ2lurgxbF+D5AYIT4o7giqtarbdgwdLntvaOuLjwr/n49siYr2rh ynuK+ayIaIwh4AZYk+O9pS/hxTItlk/5wyCToWJkXFXrEa0vQi1kCJTbFryS3mEb54Ng inkqAEfDX545Iar4UCzSB4BmW5SO2eejc2h/xofb+hd8f2IB7YIsOfdWUyMSSkRI/ibp oODlapMtKUrYJRNiU0wb5oonoplRayOZRCQsp82DjZS8jaI5KdBuQhbUokJegydm9HwE Of/vIcTOYymcHDQRFRnxjk3xiQJRYqzDijRrW4DLfSkNuk9/DoYM80LvY3Wc9/e1EXT2 HZ3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=z7Jk5kZUgCJZ/VqKyob9Qa1g3SkLh/K7wnRkEtrITuc=; b=mt2pnRf56azO+1h3V0dL8YYmZdHGE2+e3apxFmhYtqHEwN1sP7eFs6NEZ94fRvg36+ 7xb2Z2iF6WHcP5W/D23yj5IHKWJrV169xy3UH6pTXpQ6KzF8/nG6E3QsFl1MlgSfVDMe uyd5SoROHBDyColS56l3hJMfKxq+Z5EsPa7Y7mgQ8yxF/8oJjJt+bj7yPqEben8aig9n qWH3vY1T9w+jjpRb1Ep00tWVaoq90qzYUONl+tVCl5SS47NfqCf7fJbniBvhk/2gOISB bOvuguNQXvrvynVqNtMFXGXpVg/6GVpFJCgoY2ij8ZKN5lVm7Rjsic6Qx2YT+rs/e7iH RPkg==
X-Gm-Message-State: AJcUukcfdLpiCuvmBTPatTooJzR/0R4T9mEoDDWVvbQStDvAtxGkc2s8 rrHId3vKFZHFsXiknb/61egu37sHxyIlwn9WuYhBMw==
X-Google-Smtp-Source: AHgI3Ibw7jxdRuXwt7e0q12AdORHo89II5ncnnPA/oDCbILsLLwgsQUopVQR55l2julTfffhIb9XTh78CoMrCMUXz6A=
X-Received: by 2002:aca:1b13:: with SMTP id b19mr13244017oib.215.1548884688369; Wed, 30 Jan 2019 13:44:48 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Jan 2019 21:44:47 +0000
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Wed, 30 Jan 2019 21:44:47 +0000
Message-ID: <CAMMESsyZyS9RHG=jm0u8P+UmwtkfJr=mpagbiiA7FXROLTDT6Q@mail.gmail.com>
To: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a5fd630580b3d1a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-CZGAiC8D3KogLnUs6ClW_KlU24>
Subject: [Idr] BGP-LS TLV Error Conditions
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2019 21:44:57 -0000
[Speaking as a WG participant.] Dear idr WG: tl;dr I think that rfc7752 doesn't do a good job in specifying actions resulting from error conditions related to the use of TLVs. As you all know, rfc7752 defines a set of TLVs to be used in describing the different Link-State NLRI types, or in the BGP-LS Attribute. The use of these TLVs is specific to the reason they were created, and in most cases that use is very clear; for example, the "Local Node Descriptors TLV contains Node Descriptors for the node anchoring the local end of the link. This is a mandatory TLV in all three types of NLRIs (node, link, and prefix)." However, it is not clear what should happen if the Local Node Descriptors TLV (for example [*]) is present in the BGP-LS Attribute. I think that the easy answer is that it should simply be ignored...silently ignored. But the text doesn't say what to do...at least I didn't find it anywhere. §3.1 (TLV Format) offers the following: "Unrecognized types MUST be preserved and propagated." The Local Node Descriptors TLV is not really "unrecognized", but I can imagine that an implementation can interpret it that way. IOW, if the Local Node Descriptors TLV was received in the BGP-LS Attribute then it would not be processed, but it would be propagated...which is akin to silently ignored... Is this the right interpretation: should "unrecognized" be interpreted also as "not belonging here"? Are there cases where it is not as clear to determine what should be "unrecognized"? Personally, I find the interpretation above to be a stretch, and not all TLV descriptions are as specific as the one for the Local Node Descriptors TLV, which "is a mandatory TLV in all three types of NLRIs". Other text say things like: "Node attribute TLVs are the TLVs that may be encoded in the BGP-LS attribute with a Node NLRI"..."following Link Attribute TLVs are valid in the BGP-LS attribute with a Link NLRI" (are others not valid?)... Other parts of rfc7752 also talk about how to handle TLVs, but I think they also paint an incomplete picture: - §3.1 also says: "In order to compare NLRIs with unknown TLVs, all TLVs MUST be ordered in ascending order by TLV Type. If there are more TLVs of the same type, then the TLVs MUST be ordered in ascending order of the TLV value..." I'm assuming that "unknown" is the same as "unrecognized"... This text doesn't talk about what should be done if the ordering is not ascending...should the TLVs be ignored? "treat-as-withdraw" [rfc7606]? - §3.2.1.4 (Node Descriptor Sub-TLVs) has similar ordering requirements for sub-TLVs... - §6.2.2 (Fault Management) talks about syntactic checks that can lead to "attribute discard", but it says nothing about finding "unrecognized" or unordered TLVs. In summary, I think that rfc7752 could use a refresh (or another document Updating it) related to the handling of TLVs. Yes, we should have been clearer when rfc7752 was published, but we weren't. :-( I'm hoping that implementers, who should have already made decisions on these topics, can take on this work. Any volunteers? [Personally, I haven't coded an implementation, but would be willing to help if needed.] Thanks! Alvaro. [*] Just using the Local Node Descriptors TLV to illustrate...
- [Idr] BGP-LS TLV Error Conditions Alvaro Retana