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

Hannes Gredler <hannes@juniper.net> Tue, 02 September 2014 08:24 UTC

Return-Path: <hannes@juniper.net>
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 686141A00D6 for <ospf@ietfa.amsl.com>; Tue, 2 Sep 2014 01:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 zyX2w3bDCQnU for <ospf@ietfa.amsl.com>; Tue, 2 Sep 2014 01:24:03 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E69F1A0127 for <ospf@ietf.org>; Tue, 2 Sep 2014 01:24:02 -0700 (PDT)
Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB521.namprd05.prod.outlook.com (10.141.72.13) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 08:24:00 +0000
Received: from hannes-mba.local (193.110.55.13) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 08:23:58 +0000
Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 455922A6F62; Tue, 2 Sep 2014 10:23:42 +0200 (CEST)
Date: Tue, 2 Sep 2014 10:23:42 +0200
From: Hannes Gredler <hannes@juniper.net>
To: "A. Przygienda" <prz@zeta2.ch>
Message-ID: <20140902082342.GB39341@juniper.net>
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <D010DA98.1B41%acee@cisco.com> <5404E67E.6050407@zeta2.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5404E67E.6050407@zeta2.ch>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Originating-IP: [193.110.55.13]
X-ClientProxiedBy: DB4PR06CA0037.eurprd06.prod.outlook.com (25.160.40.165) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:;
X-Forefront-PRVS: 0322B4EDE1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(199003)(105586002)(74502001)(23726002)(106356001)(4396001)(77982001)(76506005)(77096002)(31966008)(74662001)(86362001)(87976001)(46406003)(102836001)(46102001)(33656002)(95666004)(107046002)(230783001)(92726001)(50466002)(47776003)(50986999)(21056001)(85306004)(54356999)(76176999)(83506001)(83322001)(80022001)(76482001)(101416001)(92566001)(110136001)(81542001)(97756001)(83072002)(85852003)(90102001)(99396002)(64706001)(20776003)(66066001)(36756003)(81342001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/phc0Yev2rS_CP1-m387xJFjneWk
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: Tue, 02 Sep 2014 08:24:05 -0000

hi tony,

requiring send-side ordering is certainly intended well,
but that in itself does not guarantee ordered delivery
at the receiving end :-/.

IOW in case you have an application that needs both
the 1) prefix-LSA and the 2) extended-prefix-LSA you need
to have the logic that checks presence of 1)
at the receiving end anyway.

rather than doing things on the send-side let me suggest
to check if you have got your act together during
route-computation time. (this is a bit akin to
IS-IS fragment zero handling - ala - if frag zero
is not present then all non-zero
frag content has to be disregarded).

HTH,

/hannes

On Mon, Sep 01, 2014 at 02:34:54PM -0700, A. Przygienda wrote:
[ ... ]
|    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.
| 
|    --- tony