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

Peter Psenak <> Tue, 02 September 2014 07:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 204BA1A00B0 for <>; Tue, 2 Sep 2014 00:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lGNFEpVCiCwb for <>; Tue, 2 Sep 2014 00:25:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B4B81A00AA for <>; Tue, 2 Sep 2014 00:25:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3343; q=dns/txt; s=iport; t=1409642742; x=1410852342; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=TpJ+GRIKIsXTTBA9BZHXV/6E80/V10JxPWlD5ZmDvQk=; b=jCZiV4rF3aVuYimEHgZN8RBTNh80I760QHKh6Y5KiGnVdERzlgOQANFL /pK4J5LosXMz2pYDiURbgxroifWRGqvxGuSOhrcgGzYgXEt+G8/QLNb8w Xo1JbUDie6bInARMh8u/lbhT5XTz1KwwapGZ6+XKGNn0vHj6ElbfVQl+m A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,447,1406592000"; d="scan'208";a="158108750"
Received: from (HELO ([]) by with ESMTP; 02 Sep 2014 07:25:38 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s827PcxO012964; Tue, 2 Sep 2014 07:25:38 GMT
Message-ID: <>
Date: Tue, 02 Sep 2014 09:25:38 +0200
From: Peter Psenak <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "A. Przygienda" <>,
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Sep 2014 07:25:46 -0000

Hi Tony,

please see inline:

On 9/1/14 23:34 , A. Przygienda wrote:
> 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

as far as the information in the two LSAs are the same, having the 
prefix in two LSAs with different flooding scopes is not a problem - 
happens today with regular LSAs.) The problem would be if the content of 
TLVs associated with the prefix is controversial, in which case it would 
be a defect on the originator side.

> 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.

no, that is a valid case. One may want to advertise some extended prefix 
attributes without advertising the prefix's reachability.

> 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]'  ?

LSA can only have single flooding scope, so all information inside LSA 
is limited to that flooding scope. That is what was meant by the above 

> 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.

as I said, not flooding regular LSA, only extended LSA is a valid case.

> --- 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
> _______________________________________________
> OSPF mailing list