Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

"Alvaro Retana (aretana)" <> Fri, 16 October 2015 14:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24BAA1B2C2C; Fri, 16 Oct 2015 07:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p4yYyayoockX; Fri, 16 Oct 2015 07:23:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4CD501B2C1E; Fri, 16 Oct 2015 07:23:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2288; q=dns/txt; s=iport; t=1445005405; x=1446215005; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1f/tOXcH4mxckt4URgKp7PHQvazwLAgVKVUGLkNCWmo=; b=DBMCsfKAHl3ep4ZARbqxc8P4KMllYnTpnjpSOpHH7an1sLagJ0g3Hliu lv14r3eeOfD6mAHFyFSyimEx+dhKUwEzDhy/cZrV0eFfQU/U5B4Dkj4zF YkPwIgmZ1yfZA3rApNyfQUEM+FKckd9gIm60JCPEZhMcYnJi/7FIL8u/m 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,689,1437436800"; d="scan'208";a="38188727"
Received: from ([]) by with ESMTP; 16 Oct 2015 14:23:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t9GEN8Hn023820 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2015 14:23:08 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 16 Oct 2015 09:22:53 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Fri, 16 Oct 2015 09:22:53 -0500
From: "Alvaro Retana (aretana)" <>
To: Rob Shakir <>, Shraddha Hegde <>, The IESG <>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)
Thread-Index: AQHRBcJuCumG1ZA/D0Cj5vEpcyU0Zp5sUYCAgAAuTQCAAbA8AP//5uGAgABXaoD//9NAgA==
Date: Fri, 16 Oct 2015 14:22:53 +0000
Message-ID: <>
References: <> <> <> <> <> <etPan.5620f609.42befee7.19d1@piccolo.local>
In-Reply-To: <etPan.5620f609.42befee7.19d1@piccolo.local>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)
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, 16 Oct 2015 14:23:27 -0000

On 10/16/15, 9:03 AM, "Rob Shakir" <> wrote:



>Picking up on one particular point:

Are you advocating for the draft to specify an ordering scheme, or at just
leaving it at "MUST be considered unordered"?  Your text below says one or
the other, just wondering about preference.



>On 16 October 2015 at 05:50:48, Alvaro Retana (aretana)
>( wrote:
>> > What we're not in agreement on is the fact that if an implementation
>> chooses to implement an order (as you said above "Implementations
>> are free
>> to pick any order"), and provides policy constructs to act on
>> the order
>> (implementation-specific detail), then the operator can use
>> those features
>> to his/her advantage regardless of what this document says.
>> IOW, "MUST be
>> considered an unordered list" doesn't reflect a reasonable
>> expectation and
>> can't really be enforced.
>I think the opposite is true. If we have no guarantee of order, then
>vendor C can sort tags numerically ascending, and vendor D can sort tags
>numerically descending. Based on this, one could have a policy that
>matches (1 BEFORE 2) which is triggered only when advertisements are
>received from a vendor C box, and not a vendor D one.
>Given that operationally, we do not care whether it was a vendor C or D
>box [0], then this actually will mean that we have different logic
>applied based on the implementation choice. If we are to allow tags to be
>combined non-commutitvately, then we need to have logic that says that
>the ordering matters (and defined how it is done). If we do not, then we
>need strong guidance to implementors (of the specification AND operators)
>that they cannot rely on order.
>A murky middle ground is that we end up with inconsistent treatment of
>tags across different implementations, which creates pain for network
>operators trying to use them, or introducing a new implementation into
>their network (all policies that previously worked based on order,
>suddenly don¹t based on this new implementation having different logic).
>[0]: And if we did, we could just create a new tag that specifies the
>vendor, like we could have one that specifies the role.