[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...