Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: [1] Operational Considerations

["Black, David" <[e-mail]>]

The new Operational Considerations text that Shradda sent out looks good.

I'd like to make one small change to avoid overusing the concept of
preference/preferred:

   Defining language for local policies is outside the scope of this
   document.  As in case of other policy applications, the pruning
   policies can cause the path to be completely removed from forwarding
OLD
   plane, hence are less preferred than the preference policies.
NEW
   plane, and hence have the potential for more severe operational
   impact (e.g., node unreachability due to path removal) by comparison
   to preference policies that only affect path selection.

Beyond that, I thought I saw some agreement that Section 4.5 warrants
some text editing to better reflect this pruning vs. preference
distinction - did Bruno volunteer to draft that text?

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, October 07, 2015 5:48 AM
> To: Shraddha Hegde; Black, David
> Cc: [e-mail]; [e-mail]; [e-mail]; Rob Shakir; [e-mail];
> [e-mail]; General Area Review Team ([e-mail]);
> [e-mail]
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06
> 
> Shraddha, David,
> 
> > From: Shraddha Hegde [mailto:[e-mail]] > Sent: Wednesday,
> October 07, 2015 9:08 AM
> 
> [...]
> 
> > -- 4.5.  Explicit routing policy
> >
> > In Figure 3:
> > - The link from the leftmost pair of A nodes to the pair of T nodes
> >    do not have link weights.
> 
> [Bruno] There is some trade-off between adding more information on the figure
> and its readability.
> Metrics value on links AT have no impact on routing assuming they have the
> same value on both planes and that links in the lower/side of the network are
> higher than link in the upper/core.
> The former is the case for links in the figure, and the latter is rather
> typical in network, so I had assume that the metrics could be removed in order
> to improve readability.
> But I agree that from the asci art, this is not that evident.
> Metric would be 10.
> Shraddha, you can either update the  figure or send me the latest xml for
> update.
> 
> > - The link from the left R node to the left T node does not have a
> >    link weight
> 
> [Bruno] Yes. Lack of space in the figure.
> Another option is to add a text to specific the metrics. e.g.
> 
> Proposed NEW:
> Links between T, R and I nodes have a metric of 100.
> Links between A nodes and R and T nodes have a metric of 10.
> Links between A nodes and I nodes have a metric of 201.
> 
> 
> Do you think this would be clearer?
> 
> > - 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?
> 
> [Bruno]
> In this specific example, the policy would be
> "      - Traffic from A nodes to A nodes should preferably go through R or T
> nodes (rather than through I nodes)
>       - Traffic from A nodes to I nodes must not go through R and T  nodes"
> 
> 
> Indeed, in the latter case, loss of connectivity (in case of double
> independent failures) is preferred over using R or T nodes. (FYI in this case,
> network would not have enough capacity to carry the traffic in case of these
> double failures. It has been preferred to conceal the impact of the failure to
> a limited network area, rather than impacting another one. Trade-off again,
> but double independent failures have very low probability. In case of such
> "catastrophic"/hypothetic failure that the network is not capable of handling,
> experience shows that it's usually a good idea to try limiting the scope of
> the problem, rather than taking the risk to impact the whole network. At least
> until someone have a look at the problem and take a decision.)
> We may change the text, if you want, in order to exactly refer to this
> example. But this is just an example, and the one written in the document is
> equally valid.
> 
> 
> > Also: "explicitly routed policies" -> "explicit routing policies"
> 
> [Bruno] yes, Thanks
> 
> 
> > <Shraddha> It's probably not intended.
> > Bruno, can you pls confirm?
> 
> [Bruno] Done.
> 
> 
> > But, the example in itself is very much valid, with node admin tags
> operators
> > can
> > have policies to drop traffic if destined towards certain prefixes.
> > As Rob and Bruno, this is nothing new as such an operation is possible today
> > with routing policies.
> 
> -- Bruno
> 
> 
> ______________________________________________________________________________
> ___________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.