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

"Acee Lindem (acee)" <> Tue, 02 September 2014 13:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60A1B1A8829 for <>; Tue, 2 Sep 2014 06:40:33 -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 C6rqSMjZ0505 for <>; Tue, 2 Sep 2014 06:40:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF67D1A8758 for <>; Tue, 2 Sep 2014 06:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4451; q=dns/txt; s=iport; t=1409665062; x=1410874662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QssAkOiedoEEE8Ft9BSFCbcM9ibe7UPzU7eNYgdya/Q=; b=k3wUK6TTQe0ang99z0AuoTnr2S+6lBRxuCKtEUClChD/SXkcMeELqsKZ us3VBbD0zwyMFGg10UJz+oR+TOXuGhaADYsPviFIdhql70Xsmvof/oQvW wuzEpLmLAtp6tl0XeDmSehPWXVNrIogQlPTfLeK8ZYJzNIzQ9bflOafCL E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,449,1406592000"; d="scan'208";a="351735342"
Received: from ([]) by with ESMTP; 02 Sep 2014 13:37:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s82DbfpL015233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 13:37:41 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 08:37:40 -0500
From: "Acee Lindem (acee)" <>
To: "Peter Psenak (ppsenak)" <>
Thread-Topic: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
Thread-Index: AQHPtlGQNLZvkWuqU0uFf/90h1EvfZvOlLMAgB6rngCAAKUNAIAAZ/CA
Date: Tue, 2 Sep 2014 13:37:40 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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 13:40:33 -0000

Hi Peter, Tony, 

On Sep 2, 2014, at 3:25 AM, Peter Psenak <> wrote:

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

This is another case where the segment routing mapping server requirement makes this more complicated. I think the guidance for the case should be to give preference to the information in the LSA with area flooding scope. 

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

Actually, I had considered removing this statement when I separated the generic protocol extensions from the SR specific draft. 

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

In any case, an application using extended attributes will need to be triggered by the extended prefix/link attribute LSAs.  The advertising router may originate one or both of them independently. I will try to capture this disjointness in a paragraph. 


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