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

Rob Shakir <> Fri, 16 October 2015 13:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 98CF21B2A02; Fri, 16 Oct 2015 06:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L2LtcrNxMBsw; Fri, 16 Oct 2015 06:05:22 -0700 (PDT)
Received: from ( [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E02B1B29D4; Fri, 16 Oct 2015 06:05:21 -0700 (PDT)
Received: from [2601:681:201:5165:4c6f:3d4c:626f:3130] (helo=piccolo.local) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1Zn4gu-00013m-Fr; Fri, 16 Oct 2015 14:05:00 +0100
Date: Fri, 16 Oct 2015 07:03:13 -0600
From: Rob Shakir <>
To: Shraddha Hegde <>, The IESG <>, "Alvaro Retana (aretana)" <>
Message-ID: <etPan.5620f609.42befee7.19d1@piccolo.local>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Airmail Beta (334)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <>
Cc: "=?utf-8?Q?" <>, "=?utf-8?Q?" <>, "=?utf-8?Q?" <>, "=?utf-8?Q?" <>, "=?utf-8?Q?" <>
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 13:05:24 -0000


Picking up on one particular point:

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.