Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06

Rob Shakir <> Tue, 06 October 2015 17:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 450721AD084; Tue, 6 Oct 2015 10:22:07 -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 bIhLv_GGQnaO; Tue, 6 Oct 2015 10:22:05 -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 19B571AD09A; Tue, 6 Oct 2015 10:22:03 -0700 (PDT)
Received: from [] (helo=corretto.local) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZjVvm-0000WV-9f; Tue, 06 Oct 2015 18:21:38 +0100
Date: Tue, 06 Oct 2015 18:21:53 +0100
From: Rob Shakir <>
To: "" <>, "" <>, "Black, David" <>, "" <>, "" <>, "General Area Review Team (" <>, "" <>
Message-ID: <etPan.56140332.657fa99c.208@corretto.local>
In-Reply-To: <>
References: <> <etPan.5613e757.1304c9b1.208@corretto.local> <>
X-Mailer: Airmail Beta (331)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <>
Cc: "" <>, "Black, David" <>, "" <>
Subject: Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06
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: Tue, 06 Oct 2015 17:22:07 -0000

On October 6, 2015 at 17:46:41, Black, David ( wrote:
> Rob,
> > Given that we are really selecting candidates from within a set of paths that
> > have already been selected by OSPF as valid, and usable - then I’m not sure
> > that I can understand the logic behind this sentence from your review: "There
> > appears to be more than enough enabled by this draft to wreak serious
> > operational havoc”.
> Perhaps, I'm not understanding something, but I thought I saw an unreachability
> problem in the example in Section 4.5/Figure 3:
> - The following example of an explicitly routed policy:
> - Traffic from A nodes to I nodes must not go through R and T
> nodes
> prevents the leftmost pair of A nodes from sending traffic to the
> I nodes. Was this "black hole" intended as part of the example?
> Was that a mistake, and at least one path from the leftmost pair of A nodes
> to the I nodes will be selected despite that "explicitly routed policy”?

If the operator chooses to deny prefixes being installed in the RIB based on these tags, then yes, they could end up with unreachability problems. However, an operator can do this today with any routing policy (a number of implementations already have inbound route filtering) - we should not prevent this kind of mechanism based on the fact that an erroneous config might be problematic.

In the case that the operator *preferences* things based on the tags, then this would not be an unreachability problem - OSPF would still correctly determine that there is a path between all nodes in the pictured network - and this would be installed in the RIB as per normal operation.

(My memory is not 100% clear on whether this is intended as part of the example, if it is, then the text should be clarified I agree.)

Kind regards,