Hi Shraddha & Acee, On Mon, Nov 16, 2015 at 12:52 PM, Shraddha Hegde <[email protected]> wrote:
> Hi Acee/Alia, > > > > Pls see inline.. > > > > *From:* Acee Lindem (acee) [mailto:[email protected]] > *Sent:* Wednesday, November 11, 2015 2:11 AM > *To:* Alia Atlas <[email protected]> > *Cc:* Shraddha Hegde <[email protected]>; OSPF WG List <[email protected]>; > OSPF ADs <[email protected]> > *Subject:* Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags > > > > Hi Alia, Shraddha, > > > > *From: *Alia Atlas <[email protected]> > *Date: *Sunday, November 8, 2015 at 1:59 AM > *To: *Acee Lindem <[email protected]> > *Cc: *Shraddha Hegde <[email protected]>, OSPF WG List <[email protected]>, > OSPF ADs <[email protected]> > *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) <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ospf > > > >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
