Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Shraddha & Acee,

On Mon, Nov 16, 2015 at 12:52 PM, Shraddha Hegde <shraddha@juniper.net>
wrote:

> Hi Acee/Alia,
>
>
>
> Pls see inline..
>
>
>
> *From:* Acee Lindem (acee) [mailto:acee@cisco.com]
> *Sent:* Wednesday, November 11, 2015 2:11 AM
> *To:* Alia Atlas <akatlas@gmail.com>
> *Cc:* Shraddha Hegde <shraddha@juniper.net>; OSPF WG List <ospf@ietf.org>;
> OSPF ADs <ospf-ads@tools.ietf.org>
> *Subject:* Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags
>
>
>
> Hi Alia, Shraddha,
>
>
>
> *From: *Alia Atlas <akatlas@gmail.com>
> *Date: *Sunday, November 8, 2015 at 1:59 AM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *Shraddha Hegde <shraddha@juniper.net>, OSPF WG List <ospf@ietf.org>,
> OSPF ADs <ospf-ads@tools.ietf.org>
> *Subject: *Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags
>
>
>
> Hi Acee,
>
>
>
> Thanks very much for reading through and pulling out the relevant
> questions.
>
> I'd like to see this conversation resolve quickly.
>
>
>
> On Sat, Nov 7, 2015 at 9:58 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
>
> Hi Shraddha,
>
> I’ve read through this discussion and I’m wondering why we just can’t
> remove this normative text with respect to the interpretation of OSPF Node
> Admin tags?
>
>    1. Since the tags are advertised by a single node, why is do they have
> to be unordered? It seems there should be a reason for this even if this
> semantic is retained.
>
>
>
> I can understand this restriction in terms of implementation complexity &
>
> assumptions.  A router that receives the tag list might want to store them
> in
>
> numerical order or such for easier searching.  If the tag order matters,
> there
>
> can be rather different requirements in terms of how the listener uses the
>
> information.
>
>
>
> Perhaps the answer is that we don’t see a use case for maintaining tag
> order given that they may come from multiple sources it adds a lot of
> complexity to try and maintain order. Note that the order independence is
> also in RFC 5130 (IS-IS prefix admin tags) - see section 4.
>
>
>
> <Shraddha> The restriction of keeping the tag set unordered ensures that
> the vendor policy implementations will use node tags as a set and not as an
> ordered list.
>
>                        Since there are no standards defined for policy
> module, its hard for the operators  to guess how the vendor policy
> implementations behave.
>
>                        I think the explicit mention of the tag ordering
> ensures there is no ambiguity in interpreting the tags.
>

 Ok - this makes sense to me.  Let's keep that restriction.

>
>
>    2. Why can’t they be advertised in multiple flooding scopes? There
> could be one set of tags applicable at the area scope and another
> applicable at the AS wide scope.
>
>
>
> I agree that I don't see implementation complexity logic driving this.
> Perhaps
>
> it allows for storing tags per device in a flat structure instead of
> requiring that
>
> they are stored per area?
>
>
>
> I wouldn’t think so.
>
>
>
>
>
> Regardless, this feels like it has more impact on operational complexity of
>
> having to define the same meaning for different tags for different areas.
>
>
>
> This restriction of a single flooding scope wouldn’t preclude this.
>
> <Shraddha> Tags are independent characteristics of a node. It’s perfectly
> valid to advertise same tag in different areas so operator need not
>
>                        Define different tags having same meaning for
> different areas.
>
>                        Since tags are independent characteristics it is
> well defined whether that characteristic need to be seen by AS wide nodes
>
>                        Or area wide nodes.
>

This sounds like an assumption on the meaning for tags that they won't need
to be sent in different
scopes.  I'm not hearing a strong reason to force this assumption.  Let's
relax it in the draft.

If the WG is ok with this resolution, could we get an updated draft this
week so I can approve the draft?

Thanks,
Alia

> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
>
> Regards,
>
> Alia
>
>
>
> In essence, since the tags are purely opaque, it seems you could simply
> remove the last 2-3 paragraphs of section 3.2.1 and the last paragraph of
> section 3.2.2 as these seem to be rather arbitrary restrictions.
>
> Thanks,
> Acee
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>
>