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

Peter Psenak <ppsenak@cisco.com> Fri, 05 September 2014 08:34 UTC

Return-Path: <ppsenak@cisco.com>
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 3D22A1A0674 for <ospf@ietfa.amsl.com>; Fri, 5 Sep 2014 01:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ftMmr_kN8dG for <ospf@ietfa.amsl.com>; Fri, 5 Sep 2014 01:34:14 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE241A0075 for <ospf@ietf.org>; Fri, 5 Sep 2014 01:34:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5777; q=dns/txt; s=iport; t=1409906048; x=1411115648; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=sa+XQf8gQHo3096l6o2rIuI+d7d02NxTZfuyeULSbJw=; b=i9AMkvHCtzMat21SBrY9We0JtA1aVQAVZHbjZ7nUx5pKr2TuocgqzRUd q1kHIibFBolxfBX4mW2UDR1toKRk0Zrx4tut1sjNifBJuJeY4cmmFWKMS eEDG0n7jhT9U0I+RDvTxHzEqwKtIM9sB/GRrqSoRpjmCwj4lE9z7hxlrl o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsEAHJ0CVStJssW/2dsb2JhbABZg2BXyEsKh0wBgSB3hAMBAQEEAQEBNTYJARELGAkWDwkDAgECARUnCQYBDAYCAQEXiCcNvWsBEwSPVIRMAQScbIc5jWmCG4FIOy+CTwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,471,1406592000"; d="scan'208";a="166802005"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Sep 2014 08:34:06 +0000
Received: from [10.55.51.206] (ams-ppsenak-87113.cisco.com [10.55.51.206]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s858Y4de003037; Fri, 5 Sep 2014 08:34:06 GMT
Message-ID: <5409757C.7040600@cisco.com>
Date: Fri, 05 Sep 2014 10:34:04 +0200
From: Peter Psenak <ppsenak@cisco.com>
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" <prz@zeta2.ch>, ospf@ietf.org
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>
In-Reply-To: <5408B75E.4040106@zeta2.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0g8xm5icxlhG3BeZe5OmV3-b5M0
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: Fri, 05 Sep 2014 08:34:18 -0000

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 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.
>
> 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 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.
>
> agreed here. you're correct. That would be overspecification in this 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.
>
> 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 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.
>
> 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 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.
>
> 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 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.

thanks,
Peter
>
> --- tony
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> .
>