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

["Acee Lindem (acee)" <[e-mail]>]

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" <[e-mail]> 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: [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.
>