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

Peter Psenak <> Thu, 04 September 2014 07:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3ECA91A6EE4 for <>; Thu, 4 Sep 2014 00:24:27 -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 snEbLAX17y_y for <>; Thu, 4 Sep 2014 00:24:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF2441A2130 for <>; Thu, 4 Sep 2014 00:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7807; q=dns/txt; s=iport; t=1409815465; x=1411025065; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tCi8FznZFk0ge0d/50bFrijQ49Pm60e3pHThvmrmtJw=; b=N2oBLgzc7BY/bATnw344tb9skFwq5PjcIpvKNKGp6+5PLowhBA5bILtx 0nJGKQDMEVAMm+pj3dL0KxZRSUPE6OLFBH1OPGpHMULqQcUnsuSTbsDtc vnXM7eNMx6yS4LvNz0GQQNOHKm5BEdkVp5WUUb49Nu42ofVCwm6HkksVu Y=;
X-IronPort-AV: E=Sophos;i="5.04,464,1406592000"; d="scan'208";a="160681988"
Received: from (HELO ([]) by with ESMTP; 04 Sep 2014 07:24:23 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s847OMpg022161; Thu, 4 Sep 2014 07:24:23 GMT
Message-ID: <>
Date: Thu, 04 Sep 2014 09:24:23 +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" <>, "Acee Lindem (acee)" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Thu, 04 Sep 2014 07:24:27 -0000

Hi Tony,

please see inline:

On 9/3/14 18:13 , A. Przygienda wrote:
> Hey Acee,
>>>> 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.
> agree.  preferring area (or in extreme case link scope ?) is simplest
> resolution of the issue. Agree with Acee here.
> It's also wise to add 'if the same extended prefix TLV (i.e. for same
> prefix) is seen twice in same opaque LSA only use the first and force
> people to put all sub-tlvs into a single tlv.

it's kind of obvious, but we can add a text to be sure.

>>>> 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.
> Here I think the draft may benefit from some clearer writing. Even an
> experienced OSPF reader is lead to assume that original LSA must be
> present to use the extended.
> "OSPFv2 requires functional extension beyond what can readily be done
> with the fixed-format Link State Advertisements (LSAs) as described
> in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
> on Type-Length-Value (TLV) tuples that can be used to associate
> additional attributes with advertised prefixes or links."
> That's strongly suggestive of "you advertise normal LSA and then you use
> opaque to 'extend' it" . Extended extends and is not independent from
> original stuff in normal use of English idiom.

because existing LSA are not extensible, any additional link/prefix 
attributes must be advertised in a separate LSAs. We called it 
"extended", but it does not mean that existence of the extended LSA 
require existence of the base LSA. I had a text in the original SR draft 
around that, we can add it here too.

> On top, if you start to advertise opaques & people start to compute
> reachability or distance based on opaques (unless you specificall state
> in this draft that it _cannot_ be used for that purpose, i.e. opaque
> influences reachability or computed metric) and you can have routers in
> the area that do not support opaques, an additional text is needed
> saying  "never compute through routers without opaques using information
> in opaques that influences reachability or metrics". Actually, it's
> worse since if a router without opaques forwards through a router
> advertising opaques influencing metrics (for sake or simplicity), you
> cannot start using opaques to keep on forwarding.  In case that all
> doesn't parse, I can do a simple looping example.

we are not advertising any metrics in the extended LSAs, so I do not see 
why we would have to deal with that case here. If one day someone wants 
to do that, then it would have to be covered in a separate draft and we 
would deal with it at that time.

>>>> 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.
> OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
> type-5 one or the 'opaque flodding scope one'.  I think you mean 'all
> prefixes in the same opaque must have the same OSPF-route-type
> [0+unevens]'  but the text is really hard to parse here.
> Acee, you mean remove the restriction ?  I see how some implementations
> may benefit from cramming all type-3 into the same opaque but I would
> also suggest to not restrict this and remove the text.

the restriction can not be removed. All the Extended Prefix TLVs that 
you put in a singe Extended Prefix LSA will only use a flooding scope of 
the Extended LSA itself.

>>>> 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.
> yes, and again, I think 'extended' is an ill chosen name maybe if that's
> the intention of the draft.
> BTW, what is the plan if all the TLVs blow out the MTU of the opaque ?

you can generate many Extended Prefix or Extended Link LSAs, so there is 
no issue.

> I'm missing something ?   RFC5250 is not describing how the instance
> (they call it Opaque ID) is supposed to be generated (it references
> appendix A referencing section 7 which has nothing in it about this).
> I'm divining the instance allows to have multiple opaques of the same
> type which leads to bunch interesting discussions
>       * what happens when the MTU gets blown & TLVs are shifted into
> next 'fragment' in ISIS speak [with all the restrictions how the TLVs
> can migrate between fragments, ISIS guys suffered this one [as did PNNI]
> @ length & will surely lend a helping hand in such a case].

TLVs can come and go and move from one Extended Opaque LSA to the other. 
Implementation needs to track these changes and deal with them.

>       * what happens if the same extended prefix TLV shows up twice in
> two different opaques of same type ?  You use the one that is in lower
> opaque ID ?

I would call it a bug on the originator side.


> All nit-picking based on ample scar tissue with TLV based protocols in
> real deployments.
> thanks
> --- tony