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

"Black, David" <david.black@emc.com> Thu, 08 October 2015 18:04 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3E11ACD92; Thu, 8 Oct 2015 11:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO2eVPCjMiYs; Thu, 8 Oct 2015 11:04:13 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502C71ACD90; Thu, 8 Oct 2015 11:04:13 -0700 (PDT)
Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t98I41LQ021371 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Oct 2015 14:04:01 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t98I41LQ021371
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1444327443; bh=2jWfQsTyb9dfJHDtQ+02Qsjss54=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=E4zZu0g321A7mEmEc85r1pW+QOy3U7kGD153DeYNQ1c7cJP70mcJX9Or8eI7xd2tr T11y7P3AMl43/wK59EM0pkFWpYzFdHo5fAc+yAp7Kxa1R1eYPdznNFjM5sbAZb8rTE 40SarBsXBwkOGfZi7sedNi5DK5u1Y8bVL4txN+bE=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t98I41LQ021371
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd01.lss.emc.com (RSA Interceptor); Thu, 8 Oct 2015 14:03:20 -0400
Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t98I3dpI020397 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Oct 2015 14:03:40 -0400
Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 8 Oct 2015 14:03:39 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.74]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0224.002; Thu, 8 Oct 2015 14:03:38 -0400
From: "Black, David" <david.black@emc.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>
Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: [1] Operational Considerations
Thread-Index: AdEB86VKx1ytIPpWR5CQB/I+kYuhWA==
Date: Thu, 8 Oct 2015 18:03:37 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936166B4BD7@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.45.83]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/lO0mSG0wWGQQcmOi_DZxSD75-ls>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <david.black@emc.com>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>, "as@cisco.com" <as@cisco.com>
Subject: Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: [1] Operational Considerations
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2015 18:04:15 -0000

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: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
> Sent: Wednesday, October 07, 2015 5:48 AM
> To: Shraddha Hegde; Black, David
> Cc: acee@cisco.com; ospf@ietf.org; ietf@ietf.org; Rob Shakir; as@cisco.com;
> ops-dir@ietf.org; General Area Review Team (gen-art@ietf.org);
> lizhenbin@huawei.com
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06
> 
> Shraddha, David,
> 
> > From: Shraddha Hegde [mailto:shraddha@juniper.net] > 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.