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

["Alvaro Retana (aretana)" <[e-mail]>]

On 10/16/15, 9:03 AM, "Rob Shakir" <[e-mail]> wrote:

Rob:

Hi!

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

Thanks!

Alvaro.


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