Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2
"Acee Lindem (acee)" <acee@cisco.com> Fri, 07 October 2016 13:59 UTC
Return-Path: <acee@cisco.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 5D6CA1295F5 for <idr@ietfa.amsl.com>; Fri, 7 Oct 2016 06:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.516
X-Spam-Level:
X-Spam-Status: No, score=-17.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FKKdRCHO7RzC for <idr@ietfa.amsl.com>; Fri, 7 Oct 2016 06:59:53 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3CE1295EB for <idr@ietf.org>; Fri, 7 Oct 2016 06:59:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65535; q=dns/txt; s=iport; t=1475848789; x=1477058389; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ngpHwSp/k+tQ/THGGmaR6jbeC2iY+f1g/lG5rb0XTTQ=; b=YtHSMi6WTsaIm59ET5cru8oQUnJy0zbrLioggjjzpgJtGvDCwUbqNP1j xsB+juoLFSk+0+al51AuSum/31iUyptr8o87aTP/I5VuxnbndiE+zui7M A9bzbLSeA2On5IzZbC2A9/i9RXW0BFPuj3gAs8+IbbXD+5uMcTIg913l1 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AmAQABqvdX/5BdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgwc2AQEBAQEeV3wHjSyXAIdYjFSCC4YgAhyBYTgUAQIBAQEBAQEBXieEYQEBAQQjClwCAQgRAwEBASEBBgMCAgIfBQwUCQgCBAERAYg2AxezAIkHDYNeAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYsRgTyBC4IXCRaCToJbBYg7YosIhSU1AYxygwiPdIhjhBSDfgEeNhoxgmgQDxmBOnKHD4EAAQEB
X-IronPort-AV: E=Sophos;i="5.31,308,1473120000"; d="scan'208,217";a="332935782"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2016 13:59:48 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u97DxmWR020555 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Oct 2016 13:59:48 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Oct 2016 09:59:47 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 7 Oct 2016 09:59:47 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, 'Mamud Hasan' <mamud.hasan@gmail.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2
Thread-Index: AQHSFobQofnMASCZJE2PqHSE7pDtN6CJZcaAgBLxcwCAAI+LAA==
Date: Fri, 07 Oct 2016 13:59:47 +0000
Message-ID: <D41CF7F3.81D76%acee@cisco.com>
References: <CAHBg-RxPZbscLfGMYyU7_8gUKC_0vR3GgHUyR-CfAByBJ3vOsw@mail.gmail.com> <9c6e95b9fd6d4f809cc5734eb124dc6f@XCH-ALN-014.cisco.com> <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk>
In-Reply-To: <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.76.45]
Content-Type: multipart/alternative; boundary="_000_D41CF7F381D76aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5cfYzZXxXaq86-bdAJBdDn2xE0Y>
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
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: Fri, 07 Oct 2016 13:59:55 -0000
One of the objectives of BGP-LS is to provide a normalized representation of the IGP link-state information independent of whether the origin is OSPF or IS-IS. For the most part, we’ve succeeded. Thanks, Acee From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> on behalf of Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> Reply-To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> Date: Thursday, October 6, 2016 at 3:25 PM To: "Jakob Heitz (jheitz)" <jheitz@cisco.com<mailto:jheitz@cisco.com>>, 'Mamud Hasan' <mamud.hasan@gmail.com<mailto:mamud.hasan@gmail.com>>, IDR List <idr@ietf.org<mailto:idr@ietf.org>> Subject: Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2 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<mailto: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<mailto: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
- [Idr] RFC7752 : Decoding clarification of BGP-LS … Mamud Hasan
- Re: [Idr] RFC7752 : Decoding clarification of BGP… Jakob Heitz (jheitz)
- Re: [Idr] RFC7752 : Decoding clarification of BGP… Adrian Farrel
- Re: [Idr] RFC7752 : Decoding clarification of BGP… Mamud Hasan
- Re: [Idr] RFC7752 : Decoding clarification of BGP… Acee Lindem (acee)