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

"Acee Lindem (acee)" <acee@cisco.com> Thu, 08 October 2015 21:51 UTC

Return-Path: <acee@cisco.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 6A9BB1B2A5A; Thu, 8 Oct 2015 14:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 h6MYJTLOTB8Z; Thu, 8 Oct 2015 14:51:41 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C311B2A53; Thu, 8 Oct 2015 14:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8544; q=dns/txt; s=iport; t=1444341101; x=1445550701; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jTbuF+kEyYpzF+IglWBhnyt4Zwe8MIl0UEGJGTfGqsU=; b=hrLD8iA40Bir87ILuWmB1mWYXLn5M0lpnt9rtMOPWvF4ZgC5egbnQqbW jnlNXXgWZdYZ70uVq6rI85LmjuD/vZCKHKxp8B5kqgncij7zFbhMxFLWC hM8lggENtLw+RQIVGn+PVCngd5NPkDB75GxsdiXNnAN3MZlis41qNYVn9 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D4AgA/5RZW/4YNJK1egyeBQga9QwENgVqDE4IKfwIcgTs4FAEBAQEBAQGBCoQmAQEBBCMEDRMyDAQCAQgRBAEBAwIfBAMCAgIwFAEICAEBBAENBYguryqFHI5/AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Eiik+EKgoHAR4IKwcCAgKCY4FFAQSSOoNQAYgGhRGBWIQ6hBqJBohIHwEBQoIRHRaBPnGGIQkXI4EGAQEB
X-IronPort-AV: E=Sophos;i="5.17,656,1437436800"; d="scan'208";a="33937496"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 08 Oct 2015 21:51:27 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t98LpRFi031472 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2015 21:51:27 GMT
Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 8 Oct 2015 16:51:25 -0500
Received: from xhc-aln-x02.cisco.com (173.36.12.76) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 8 Oct 2015 16:51:25 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0248.002; Thu, 8 Oct 2015 16:51:26 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Black, David" <david.black@emc.com>, "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+kYuhWAAKC5uA
Date: Thu, 8 Oct 2015 21:51:25 +0000
Message-ID: <D23C5D3B.34400%acee@cisco.com>
References: <CE03DB3D7B45C245BCA0D24327794936166B4BD7@MX104CL02.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936166B4BD7@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.101.220.158]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E82433BE07D48444B38506C64BD61B46@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/V54N2fAZA086J_KngZ7k4areWr0>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "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 21:51:45 -0000

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" <david.black@emc.com> 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: 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.comco.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.
>