Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06

[<[e-mail]>]

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.