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

"A. Przygienda" <prz@zeta2.ch> Wed, 03 September 2014 16:13 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 1CC121A035D for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 09:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level:
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 RQ-kKD7ijCtV for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 09:13:48 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2A1A8A68 for <ospf@ietf.org>; Wed, 3 Sep 2014 09:13:38 -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 28E8312953; Wed, 3 Sep 2014 18:13:18 +0200 (CEST)
Message-ID: <54073E17.2090407@zeta2.ch>
Date: Wed, 03 Sep 2014 09:13:11 -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: "Acee Lindem (acee)" <acee@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>
In-Reply-To: <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com>
X-TagToolbar-Keys: D20140903091311476
Content-Type: multipart/alternative; boundary="------------010708060606020607000709"
X-MailScanner-ID: 28E8312953.AC9D8
X-MailScanner: Found to be clean
X-MailScanner-From: prz@zeta2.ch
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/d7u7xg6pScvP8Q2mq9PJ0ok24Lc
Cc: "ospf@ietf.org" <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: Wed, 03 Sep 2014 16:13:53 -0000

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 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.

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.


>>
>>> 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.
>
>
>>>
>>> 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 ? 
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].
     * 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 ?

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

thanks

--- tony