Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt

"A. Przygienda" <prz@zeta2.ch> Mon, 01 September 2014 21:35 UTC

Return-Path: <prz@zeta2.ch>
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 C71B51A0ACD for <ospf@ietfa.amsl.com>; Mon, 1 Sep 2014 14:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level:
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982] autolearn=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 MpPiS4aY_Aq5 for <ospf@ietfa.amsl.com>; Mon, 1 Sep 2014 14:35:04 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 99CDE1A08BE for <ospf@ietf.org>; Mon, 1 Sep 2014 14:35:03 -0700 (PDT)
Received: from prz-workstation.zeta2.ch (108-228-12-76.lightspeed.sntcca.sbcglobal.net [108.228.12.76]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPSA id 94A86894F for <ospf@ietf.org>; Mon, 1 Sep 2014 23:34:56 +0200 (CEST)
Message-ID: <5404E67E.6050407@zeta2.ch>
Date: Mon, 01 Sep 2014 14:34:54 -0700
From: "A. Przygienda" <prz@zeta2.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: ospf@ietf.org
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <D010DA98.1B41%acee@cisco.com>
In-Reply-To: <D010DA98.1B41%acee@cisco.com>
X-TagToolbar-Keys: D20140901143454535
Content-Type: multipart/alternative; boundary="------------070301000206050703080906"
X-MailScanner-ID: 94A86894F.AAEF4
X-MailScanner: Found to be clean
X-MailScanner-From: prz@zeta2.ch
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pUZEYUhipdDqbT7pUC-45RRyYco
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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, 01 Sep 2014 21:35:05 -0000

Comments:

a)   section 1. introduction last line

> the existing LSAs will be replaced _BY_ TLV-based extended LSAs.

b) section 2.

It may be well writing a sentence or two what should happen if an OSPFv2
Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11
changes) and what should happen if the same prefix appears in two
different flooding scopes with different information (ignore prefix in
both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it
open may lead to different treatement per router and surprising effects

It may be also helpful to add that if an opaque extended is present but
the prefix (of the according type) is not in the standard LSAs, such
information must be disregarded.

c) section 2.1

> Multiple OSPF Extended Prefix
> TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but
> all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA
> MUST have the same flooding scope.

may be misleading. Since they are in a opaque, the flooding scope is
controlled by opaque. If  the type-5 vs. type-3 is meant than  'flooding
scope' must be disassociated between 'opaque flooidng scope' and
'route-type flooding scope [as in we don't flood type-1 across ABRs]'  ?


d)
I think it may be a valid suggestion to implementors that (for every
version) the  according  LSA  SHOULD be flooded _before_ the opaque LSA
is flooded (which can be tad tricky [but doable] if the opaque carries a
bunch of those]).  Yes, with reordering of flooding etc. it's not a
guarantee for anything but a good practice to give the protocol a chance
to distribute the referent (LSA) before distributing any references
(opaques) and additionally, will make sure that  LSAs which are far more
important normally get out the box before opaques.


--- tony


On 08/13/2014 06:12 AM, Acee Lindem (acee) wrote:
> Hi, 
>
> This new draft describes the generic prefix/link attribute opaque LSAs
> that were previously included in the OSPFv2 Segment Routing draft.  The
> opaque LSAs described in this draft can be used by other OSPF WG candidate
> drafts. There are already two implementations of the draft as part of
> segment routing interoperability testing. Please read and comment.
> Thanks,
> Acee 
>