Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 06 October 2016 22:26 UTC

Return-Path: <adrian@olddog.co.uk>
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 99E4012955B for <idr@ietfa.amsl.com>; Thu, 6 Oct 2016 15:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 zcQ9yUKkjcNd for <idr@ietfa.amsl.com>; Thu, 6 Oct 2016 15:26:10 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38D81294A2 for <idr@ietf.org>; Thu, 6 Oct 2016 15:26:09 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96MQ4aF013417; Thu, 6 Oct 2016 23:26:04 +0100
Received: from 950129200 (dsl-dp-81-140-96-139.in-addr.broadbandscope.com [81.140.96.139]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96MQ34P013393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2016 23:26:03 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Jakob Heitz (jheitz)'" <jheitz@cisco.com>, 'Mamud Hasan' <mamud.hasan@gmail.com>, idr@ietf.org
References: <CAHBg-RxPZbscLfGMYyU7_8gUKC_0vR3GgHUyR-CfAByBJ3vOsw@mail.gmail.com> <9c6e95b9fd6d4f809cc5734eb124dc6f@XCH-ALN-014.cisco.com>
In-Reply-To: <9c6e95b9fd6d4f809cc5734eb124dc6f@XCH-ALN-014.cisco.com>
Date: Thu, 06 Oct 2016 23:25:58 +0100
Message-ID: <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06AB_01D22028.FEAFF210"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFqRVgUGss81iGLvu0UqNA/n1G8UAH1LVbioVwLacA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22622.003
X-TM-AS-Result: No--19.135-10.0-31-10
X-imss-scan-details: No--19.135-10.0-31-10
X-TMASE-MatchedRID: 0lhM5bBmjEMDJrf2+hNOheYAh37ZsBDCC3HuWcgyQCYCgjr7b0ytGbfc 1MMYXJERHb6AXLODRl87QlE0DAcVy4iXsq96MTZ3rQcmzcV8ovzNbZoHWAcdk1mmz7LVVfOpiir SOkBVAQVAS692nLx0luZ8JvlBwtSZAOZWqwY0KQBor4yxPAz7WVsChor7BLiNIbxYwbCxGTSqM9 21CehQfBQYrVgpDiKvF+Rf1CKzofxKDZlLBSf8q/0peXGEEBlvg3XZcphu4ktXG3yI9k2vbIAuO qciU0p01eMp+in9a9PfCoL1Cy7eF/36sqVF/VZoS3OTftLNfg2U9XpVqqLhsPHFoBcOsKeziPsn ePM42N0lrqsYlHhF+jC6IPNP8UWJUeL68LoXEvwFTi5T7nLXai3S35ohUu37krNbLf4aYG5czil UefYvAz+ZqQbT6/3u3rf2hEEVSR5DSkUa9i2162uj3ZVU+M9wlIvcAfYJnEphn/chy3DQzFQ+CF 9xoc5LnE2RogVHfH2sEFKef8ZUxpcqz3g0A4fyupDIC9422DozH3zWWApNw0vAhd4DVNld+kYX4 FVnQud9xQFIjQfO0oYCheGFuxsgL3m5ejCdaFGdCtkMrsOtOpkShYcLpGH9ZM25ZAWwDYZgEEZ9 y/pY4Y0id0pIhqxT15LlVZSTLD2SjpyB+ma+j3uTVkeYosXtOS0bT53qXdU3Rx11yoeUQtuzY75 ozkkrJXN2dBx41HZcSNmWV/ZuF99faxl/I4mhngIgpj8eDcBpkajQR5gb3tZE3xJMmmXcRRgndE tDQrLNceX0dKgFgXIP2BIs91Ks7JeN3XrK2wcQyh0JKMIYvAkrYwrjkf4Y
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1AiSWVowog3hlAf3Wm1qPeWkNdk>
Subject: Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Thu, 06 Oct 2016 22:26:12 -0000

Sorry that I lost this in the blizzard of emails on large communities.
Thanks for stepping up to answer, Jakob.
 
I agree with Jakob that all the relevant link protection type data from OSPF fits into the field. The extra reserved bytes are simply padding and can be ignored (unless you are using them as a covert channel ;-)
 
Cheers,
Adrian
 
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: 24 September 2016 22:09
To: Mamud Hasan; idr@ietf.org
Subject: Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2
 
It is formatted according to the ISIS formatting, that is 2 octets.
You will need to make OSPF conform by truncating the excess octets.
 
Thanks,
Jakob.
 
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Mamud Hasan
Sent: Saturday, September 24, 2016 10:12 AM
To: idr@ietf.org
Subject: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2
 
Hi,
This is regarding doubt about decoding of BGP-LS "Link Protection Type TLV (1093)" for carrying OSPFv2 Link Protection Type value.
 
According to this RFC7752,
3.3.2.  Link Attribute TLVs
   Link Attribute TLVs are TLVs that may be encoded in the BGP-LS
   attribute with a Link NLRI.  Each 'Link Attribute' is a Type/Length/
   Value (TLV) triplet formatted as defined in Section 3.1.  The format
   and semantics of the Value fields in some Link Attribute TLVs
   correspond to the format and semantics of the Value fields in IS-IS
   Extended IS Reachability sub-TLVs, defined in [RFC5305] and
   [RFC5307].  Other Link Attribute TLVs are defined in this document.
   Although the encodings for Link Attribute TLVs were originally
   defined for IS-IS, the TLVs can carry data sourced by either IS-IS or
   OSPF.
 
BGP-LS Link Protection Type TLV
+++++++++++++++++++++++++++++++++++
   +-----------+---------------------+--------------+------------------------------+
   |  TLV Code | Description         |  IS-IS TLV     | Reference            |
   |   Point       |                               |   /Sub-TLV   | (RFC/Section)      |
   +-----------+---------------------+--------------+-------------------------------+
   |1093       | Link Protection     |    22/20     | [RFC5307]/1.2         |
   |                 | Type                      |                    |                                    |
   ------------------------------------------------------------------------------------
We can see above that For BGP-LS Link Protection Type (1093), it follows references of ISIS (RFC 5307) only. But Link Protection decoding for ISIS and OSPF is not same (as shown below). For OSPFv2 there are extra 3 octet reserved field.
 
ISIS Link Protection Type Decoding: (rfc5307)
+++++++++++++++++++++++++++++++++++
   0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Protection Cap |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 OSPF Link Protection Type Decoding: (rfc4203)
+++++++++++++++++++++++++++++++++++
     0                       1                                 2                                3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protection Cap |                    Reserved                                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
So my question is, what could be the coding of BGP-LS Link Protection Type TLV (1093) for OSPFv2 ? Should it consider the extra 3 octet reserved field and carry these reserved field value in this TLV ?
I will be grateful if receive response. 
 
Thanks,
Mamud