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

"A. Przygienda" <> Sat, 06 September 2014 14:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D53671A040F for <>; Sat, 6 Sep 2014 07:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.782
X-Spam-Level: *
X-Spam-Status: No, score=1.782 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RDNS_DYNAMIC=0.982] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id liD5Fw364O-G for <>; Sat, 6 Sep 2014 07:47:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B94311A0409 for <>; Sat, 6 Sep 2014 07:47:17 -0700 (PDT)
Received: from ( []) (Authenticated sender: prz) by (Postfix) with ESMTPSA id 83F1612AAE; Sat, 6 Sep 2014 16:47:06 +0200 (CEST)
Message-ID: <>
Date: Sat, 06 Sep 2014 07:47:01 -0700
From: "A. Przygienda" <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Peter Psenak <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-TagToolbar-Keys: D20140906074701007
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: 83F1612AAE.A8F43
X-MailScanner: Found to be clean
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: Sat, 06 Sep 2014 14:47:23 -0000

>>>> 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.
>> As I see it, the purpose of an RFC is to assure interoperability. If
>> there are two
>> interpretations available of the same packet that will make two
>> solutions not interoperable,
>> the standard has to mandate the correct one.
> ok, we will add a text to make it clear.
>>> 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.
>> yepp, once it spelled out, it's obvious but the first conclusion one
>> jumps to is that they are inter-dependent otherwise.
> ok, we will add a text to clarify.
>>>> 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.
>> I still think it's not clear what the original paragraph means.
> prefixes can have different flooding scope. Today intra-area and
> inter-area prefixes have area flooding scope and external prefixes
> have domain wide flooding scope. You can not mix prefixes of different
> flooding scope in a single Extended Prefix LSA, because Extended
> Prefix LSA can only have a single flooding scope.
yes, this is now clearly spelled out.  I suggest adding that to the
draft with a MUST NOT and addition that if they are, the behavior of the
protocol is unspecified/incorrect.
>>>>        * 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.
>> yes, but still, the draft should mandate what the desired behavior is @
>> this point in time otherwise some will use the lower ID, some higher and
>> some none of the above & the implementations will not interop ?
> ok, we will add a tiebreaker there.

All my issues have been adressed then except concerns about the 'any
prefix in any opaque'. Let me explain.

Let's say I have an extended prefix X providing service X'.  The prefix
is advertised in opaque O_1.
If I remove it from O_1 and move it to O_2 (due to running out of space,
weak implemenation and so on)
but O_1 is flooded out there before people pick up O_2, service X' will
be interrupted.

This sounds not too bad but imagine you advertise 50 new prefixes that
slide 50 prefixes from the original
O_1.  Same for deletions. Now your protocol becomes quite fragile (if
interested further,
look @ ISIS treatement of that problem)

Waiting for new version

-- -tony