Shraddha, David,
> From: Shraddha Hegde [mailto:[email protected]] > 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.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
