Hi Bruno, Did you see the action item below? It seems we are very close.
Thanks, Acee On 10/8/15, 2:03 PM, "Black, David" <[email protected]> wrote: >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: [email protected] [mailto:[email protected]] >> Sent: Wednesday, October 07, 2015 5:48 AM >> To: Shraddha Hegde; Black, David >> Cc: [email protected]; [email protected]; [email protected]; Rob Shakir; >>[email protected]; >> [email protected]; General Area Review Team ([email protected]); >> [email protected] >> Subject: RE: Gen-ART and OPS-Dir review of >>draft-ietf-ospf-node-admin-tag-06 >> >> 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
