Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
"Acee Lindem (acee)" <acee@cisco.com> Fri, 05 September 2014 12:37 UTC
Return-Path: <acee@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 1B7A71A06AC for <ospf@ietfa.amsl.com>; Fri, 5 Sep 2014 05:37:21 -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 hUa-jDm8xrpk for <ospf@ietfa.amsl.com>; Fri, 5 Sep 2014 05:37:18 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5431A06A4 for <ospf@ietf.org>; Fri, 5 Sep 2014 05:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: AiAFAOetCVStJV2Z/2dsb2JhbABZgw1TVwTIfgqHTAGBChZ3hAMBAQEEAQEBNzQJEgIBCBgeECcLHAkCBAESG4gnDb4bARMEj1SETAWRPosulSaCG4FGbIFIgQcBAQE
X-IronPort-AV: E=Sophos;i="5.04,472,1406592000"; d="scan'208";a="349756345"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 05 Sep 2014 12:37:17 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (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 xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 07:37:15 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "A. Przygienda" <prz@zeta2.ch>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
Thread-Index: AQHPtlGQNLZvkWuqU0uFf/90h1EvfZvOlLMAgB6rngCAAKUNAIAAZ/CAgAG9yoCAAP6WgIAAwyoAgADiowD///+hAA==
Date: Fri, 05 Sep 2014 12:37:15 +0000
Message-ID: <D02F2526.28BE%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> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com> <5408B75E.4040106@zeta2.ch> <5409757C.7040600@cisco.com>
In-Reply-To: <5409757C.7040600@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BA6BD1C3C8118B4A8D322F603D2CD5A5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/96p_rLUMkqdwADyjraRlQGYJaKw
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 12:37:21 -0000
Hi Tony, Peter, I plan to update the draft next week and address some of these clarifications. Thanks, Acee On 9/5/14, 4:34 AM, "Peter Psenak (ppsenak)" <ppsenak@cisco.com> 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 >>>>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 >> . >> > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf
- [OSPF] FW: New Version Notification for draft-iet… Acee Lindem (acee)
- Re: [OSPF] FW: New Version Notification for draft… A. Przygienda
- Re: [OSPF] FW: New Version Notification for draft… Peter Psenak
- Re: [OSPF] FW: New Version Notification for draft… Hannes Gredler
- Re: [OSPF] FW: New Version Notification for draft… Acee Lindem (acee)
- Re: [OSPF] FW: New Version Notification for draft… A. Przygienda
- Re: [OSPF] FW: New Version Notification for draft… A. Przygienda
- Re: [OSPF] FW: New Version Notification for draft… Peter Psenak
- Re: [OSPF] FW: New Version Notification for draft… A. Przygienda
- Re: [OSPF] FW: New Version Notification for draft… Hannes Gredler
- Re: [OSPF] FW: New Version Notification for draft… Peter Psenak
- Re: [OSPF] FW: New Version Notification for draft… Acee Lindem (acee)
- Re: [OSPF] FW: New Version Notification for draft… A. Przygienda
- Re: [OSPF] FW: New Version Notification for draft… Acee Lindem (acee)
- Re: [OSPF] FW: New Version Notification for draft… A. Przygienda