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

"Acee Lindem (acee)" <> Fri, 05 September 2014 12:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B7A71A06AC for <>; Fri, 5 Sep 2014 05:37:21 -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 hUa-jDm8xrpk for <>; Fri, 5 Sep 2014 05:37:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB5431A06A4 for <>; Fri, 5 Sep 2014 05:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6290; q=dns/txt; s=iport; t=1409920638; x=1411130238; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YY7VuQmDXiKro39bi9yGv0r1Qf5t6pOoFYsLPAiUUgI=; b=lghOWAgqdcMyCzNsYrdAXOF2TBnBl7/tgYBLhq7B7U4alhv2Nil+xbWT p1qTRTZUgpk4p6Zs9zhVesLdqhLCDxuqCvOF2tGOF3O9zFegdI5ZqFX6l LJUgun+SwoUezQKAyIKSqZljNsx83/yT38S6nOwe9h+hwXsOajrejwnW7 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,472,1406592000"; d="scan'208";a="349756345"
Received: from ([]) by with ESMTP; 05 Sep 2014 12:37:17 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s85CbFrw012832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 12:37:15 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 07:37:15 -0500
From: "Acee Lindem (acee)" <>
To: "Peter Psenak (ppsenak)" <>, "A. Przygienda" <>, "" <>
Thread-Topic: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
Thread-Index: AQHPtlGQNLZvkWuqU0uFf/90h1EvfZvOlLMAgB6rngCAAKUNAIAAZ/CAgAG9yoCAAP6WgIAAwyoAgADiowD///+hAA==
Date: Fri, 5 Sep 2014 12:37:15 +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
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: Fri, 05 Sep 2014 12:37:21 -0000

Hi Tony, Peter, 

I plan to update the draft next week and address some of these


On 9/5/14, 4:34 AM, "Peter Psenak (ppsenak)" <> wrote:

>Hi Tony,
>please see inline:
>On 9/4/14 21:02 , A. Przygienda wrote:
>> On 09/04/2014 12:24 AM, Peter Psenak wrote:
>>> Hi Tony,
>>> please see inline:
>> Hey Peter, same
>>> On 9/3/14 18:13 , A. Przygienda wrote:
>>>> 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.
>>>> "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
>>>> 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.
>> 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.
>>>> .,..
>>>> the area that do not support opaques, an additional text is needed
>>>> saying  "never compute through routers without opaques using
>>>> 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.
>> agreed here. you're correct. That would be overspecification in this
>>>> 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
>>>> 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, and again, I think 'extended' is an ill chosen name maybe if
>>>> 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.
>> ack
>>>> 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
>>>> @ 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.
>> I would let the ISIS guys chime in here. They have tons experience with
>> TLVs sliding fragments and what kind of implementation/operation pain
>> that can cause.
>>>>        * what happens if the same extended prefix TLV shows up twice
>>>> 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.
>> --- tony
>> _______________________________________________
>> OSPF mailing list
>> .
>OSPF mailing list