[OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01

Alan Davey <Alan.Davey@metaswitch.com> Mon, 07 April 2014 09:57 UTC

Return-Path: <Alan.Davey@metaswitch.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274241A06E1 for <ospf@ietfa.amsl.com>; Mon, 7 Apr 2014 02:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 s2ct5L1hZF3T for <ospf@ietfa.amsl.com>; Mon, 7 Apr 2014 02:57:20 -0700 (PDT)
Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4671A06D1 for <ospf@ietf.org>; Mon, 7 Apr 2014 02:57:19 -0700 (PDT)
Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Apr 2014 10:57:07 +0100
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 10:57:10 +0100
From: Alan Davey <Alan.Davey@metaswitch.com>
To: "ospf@ietf.org" <ospf@ietf.org>, "draft-ietf-ospf-ospfv3-lsa-extend@tools.ietf.org" <draft-ietf-ospf-ospfv3-lsa-extend@tools.ietf.org>
Thread-Topic: [OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01
Thread-Index: Ac9FAnKI5crrObGLRia8H4bMjVlUZA==
Date: Mon, 07 Apr 2014 09:57:10 +0000
Message-ID: <C2EE31C852049D499842B19FC01C0804C1DBA5EA@ENFICSMBX1.datcon.co.uk>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.71.10]
Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804C1DBA5EAENFICSMBX1datco_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pLOtfecYIqjInwD_oqdTBTv3Ico
Subject: [OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 09:57:24 -0000

Folks

I have read draft-ietf-ospf-ospfv3-lsa-extend-01 and I think that it looks good.  I have a few comments, mostly minor.  Please let me know if you have any questions on the following.

_General Points_

The TLV types are defined with global scope.  Therefore, I think it is clearer to separate the TLV definitions from the LSA definitions.  It may be better to avoid defining limits on the TLV usage in sections defining the LSAs.

For an example of where it would be better to separate the TLV definitions, in section 11, OSPFv3 E-Intra-Area-Prefix-LSA, there is a reference to TLV type 6, which is defined in section 10, OSPFv3 E-Link-LSA.

For an example of defining limits in the TLV usage in LSA definitions, in section 4:


-          "0 - Reserved".  As the Type values are OSPFv3-global in scope, should the reserved value be defined in an overall section and not in the section defining the E-Router-LSA?


-          "The Router-Link TLV is only applicable to the E-Router-LSA.  Inclusion in other Extended LSAs MUST be ignored."  This is probably true, but seems too limiting.  Should the sections defining the LSAs state which TLVs are applicable to that LSA, only, and have a default statement that other TLV (and sub-TLV) types SHOULD be ignored?

Where multiple sub-TLVs are defined, for example, in section 8, OSPFv3 E-AS-External-LSA, there should be a statement that the sub-TLVs may be in any order.

_Minor Points, Typos, etc._

Section 1, para 2: s/OSPFv3 LSA/OSPFv3 LSAs/

Section 3, last sentence: "Unrecognized types are ignored."  Is there a better section to put this statement?  Section 3 is defining the TLV format and not any actions on processing them.

Section 4:

Should there be a statement that the E-Router-LSA can contain multiple Router-Link TLVs?  This is different to RFC 3630, where an LSA can only contain one top-level TLV and this should be made explicit.

Section 5, paragraph 3: s/her/the/?

Section 6, paragraph 2: s/Network-LSA/Inter-Area-Prefix-LSA/.

Section 8; I suggest NOT specifying the TLV lengths in the format diagrams; this seems too restrictive.

Section 12; paragraph 2, "will contain an additional options bits", s/bits/bit/?

Section 12.1, paragraph 1: s/ exteneded/extended/ and s/ MixedModeOrignateOnly/ MixedModeOriginateOnly/

Section 12.1, 1.; s/orginate/originate/.

Section 12.1.1, paragraph 1; s/In these are/In these areas/.

Appendix A, ExtendedLSASupport; s/The valid value/The valid values/

Regards
Alan

Network Technologies
Metaswitch Networks

alan.davey@metaswitch.com<mailto:alan.davey@metaswitch.com>
+44 (0) 20 8366 1177
network-technologies.metaswitch.com<http://network-technologies.metaswitch.com/>