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

[Rob Shakir <[e-mail]>]

Alvaro,

Picking up on one particular point:


On 16 October 2015 at 05:50:48, Alvaro Retana (aretana) ([e-mail]) 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).

r.

[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.