[OSPF] Notes on draft-acee-ospfv3-lsa-extend-02.txt
Anton Smirnov <asmirnov@cisco.com> Tue, 17 September 2013 13:23 UTC
Return-Path: <asmirnov@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7945011E8221 for <ospf@ietfa.amsl.com>; Tue, 17 Sep 2013 06:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaA1Sq6jZi6B for <ospf@ietfa.amsl.com>; Tue, 17 Sep 2013 06:23:39 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8CF11E8458 for <ospf@ietf.org>; Tue, 17 Sep 2013 06:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7789; q=dns/txt; s=iport; t=1379424217; x=1380633817; h=message-id:date:from:mime-version:to:subject; bh=AeERaB97Zbx7TZoTtNPa4ud5My6LaxJISG1fhJROZP8=; b=iD9NGjpLwmPcWmmuQaqjpcZlMasBM+sYouMPq526puhf3/ExjrUB/Pd7 6D5EkKrsk4RsVUlSjyFzPFEbsaP/L6b1V4ynKwO8k4CLaXz/Qzus802mY o97EAcE5kRMHKZCeUutv47nbua9PF4CdfnrNHYXyU1ThfOaUIeLDHWPyD w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnsGAA5XOFKQ/khR/2dsb2JhbABbgweKEbksFm0HgiUBAQEDeQY3FhgDAgECAUsNCAEBh3kGmWOgXpQMA5Qfg1yRdIMmOg
X-IronPort-AV: E=Sophos; i="4.90,923,1371081600"; d="scan'208,217"; a="18075860"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 17 Sep 2013 13:23:35 +0000
Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8HDNXZf026666 for <ospf@ietf.org>; Tue, 17 Sep 2013 13:23:33 GMT
Message-ID: <523857D5.7050903@cisco.com>
Date: Tue, 17 Sep 2013 15:23:33 +0200
From: Anton Smirnov <asmirnov@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2
MIME-Version: 1.0
To: "ospf@ietf.org" <ospf@ietf.org>
Content-Type: multipart/alternative; boundary="------------060207010202000503080409"
Subject: [OSPF] Notes on draft-acee-ospfv3-lsa-extend-02.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 17 Sep 2013 13:23:45 -0000
Hi, a few notes on current revision of ELSA draft (starting from editorialgoing to more important). Cosmetic notes: > 6. OSPFv3 E-Inter-Area-Prefix-LSA > ... > All LSA Header fields are the same as defined for the Network-LSA. Should be IAP LSA. > Lindem, et al. Expires March 14, 2014 [Page 20] > > Internet-Draft OSPFv3 LSA Extendibility September 2013 > > > families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV > is only applicable to the E-Link-LSA. Inclusion in other Extended > LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local > Address family SHOULD be included in the E-Link-LSA. Instances > preceding the first MUST be ignored. It is probably meant to be "instances following the first ..." Page 21: > Address family SHOULD be included in the E-Link-LSA. Instances > preceding the first MUST be ignored. For IPv6 address families as > defined in [OSPFV3-AF]. Incomplete sentence. > For simplicity and to avoid the scaling impact of maintaining both > TLV and non-TLV based versions of the same LSA within a routing > domain, the basic backward compatibility mode will not allow mixing > of LSA formats. Different formats could still be supported with > multiple OSPFv3 instances and separate OSPFv3 routing domains. "Basic compatibility mode" is confusing name for a mode when instance enabled with new functionality will not even talk to instance not enabled for (or not supporting) it. Notes to functionality: Tag field in E-ASE-LSAs is made optional. Subject of propagating tags together with Intra- and Inter- area routes was raised more than once. It is very likely that sooner or later tag sub-TLVs will be proposed for Intra- and Inter- Area E-LSA. In this case implementations will have to deal with optional tag field in E-ASE LSA and tag sub-TLV in Intra-/Inter- Prefix TLV. This is inconvenient. It is better to avoid optional field in E-ASE-LSA and define tag sub-TLV for External-Prefix TLV from the beginning. > In order to retain compatibility and semantics with the current > OSPFv3 specification, each LSA MUST contain a single Inter-Area > Prefix TLV. This will facilitate migration and avoid changes to > functions such as incremental SPF computation. I appreciate ease of migration. OTOH, for better or worse but E-Intra-Area-Prefix LSA can propagate multiple prefixes in single LSA. So well-developed implementation will have to be able to work with an LSA advertising multiple prefixes. It is a pity to restrict once and forever Inter- and Ex- Prefix TLVs if Intra- does not have such limitation. To give implementations possibility of future optimizations (advertising multiple prefixes in single LSA) and still keep advantage of faster standardization and deployment I propose: - Allow Inter- and Ex- TLVs to be present more than once in respective LSAs - Stipulate that routers running in any Migration mode MUST advertise TLV only once per LSA. Thanks, Anton
- [OSPF] Notes on draft-acee-ospfv3-lsa-extend-02.t… Anton Smirnov
- Re: [OSPF] Notes on draft-acee-ospfv3-lsa-extend-… Acee Lindem