[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