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

"A. Przygienda" <prz@zeta2.ch> Sat, 06 September 2014 14:47 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 D53671A040F for <ospf@ietfa.amsl.com>; Sat, 6 Sep 2014 07:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liD5Fw364O-G for <ospf@ietfa.amsl.com>; Sat, 6 Sep 2014 07:47:20 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id B94311A0409 for <ospf@ietf.org>; Sat, 6 Sep 2014 07:47:17 -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 83F1612AAE; Sat, 6 Sep 2014 16:47:06 +0200 (CEST)
Message-ID: <540B1E65.4000508@zeta2.ch>
Date: Sat, 06 Sep 2014 07:47:01 -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: Peter Psenak <ppsenak@cisco.com>
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <D010DA98.1B41%acee@cisco.com> <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com> <5408B75E.4040106@zeta2.ch> <5409757C.7040600@cisco.com>
In-Reply-To: <5409757C.7040600@cisco.com>
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
X-MailScanner-From: prz@zeta2.ch
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/VrB55g7-xyMJ_TyUAN57byNQRaQ
Cc: ospf@ietf.org
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: 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.
ack
>
>>
>>> 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.
ack
>
>>>> 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.
ack

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