Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - Editorial comments and nits
"Black, David" <david.black@emc.com> Wed, 07 October 2015 14:50 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 A90E91A90DA; Wed, 7 Oct 2015 07:50:51 -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 wa1C-Yl5rJwV; Wed, 7 Oct 2015 07:50:49 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 7AA981A9150; Wed, 7 Oct 2015 07:50:47 -0700 (PDT)
Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t97EoW3C009664 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Oct 2015 10:50:34 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t97EoW3C009664
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1444229434; bh=vjN6r4gf6EgRUqlWI6wVyL29LlI=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GTWhr8Q1y8VWFIrtib1mUEuM2uwS9wvAKxXRzqni0BnRNTBMnv0W8rLn4WshUkz63 5axfTwNAtiW7b78TvZ6sWSLsh5y/aUE/oDiV5o2gewYdN40T7hJY3zTDnr5JIZLOue e2osIRY5HDUlxztNoI94LhHMdlizhzeSrn2BFuTA=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t97EoW3C009664
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd53.lss.emc.com (RSA Interceptor); Wed, 7 Oct 2015 10:50:25 -0400
Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t97EoKcJ024979 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Oct 2015 10:50:20 -0400
Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub31.corp.emc.com (128.222.70.171) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 7 Oct 2015 10:50:20 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.74]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0224.002; Wed, 7 Oct 2015 10:50:19 -0400
From: "Black, David" <david.black@emc.com>
To: Shraddha Hegde <shraddha@juniper.net>, Rob Shakir <rjs@rob.sh>, "as@cisco.com" <as@cisco.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "lizhenbin@huawei.com" <lizhenbin@huawei.com>
Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - Editorial comments and nits
Thread-Index: AdEBD3anXKd+jq58TPOOmx2JnY0dfA==
Date: Wed, 07 Oct 2015 14:50:17 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936166B2823@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.105.56.29]
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/6kd0DINQYagkiuFWgJwvo3b4QvI>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "Black, David" <david.black@emc.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - Editorial comments and nits
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: Wed, 07 Oct 2015 14:50:51 -0000
Most of the nits/editorial comments are fine. Two follow-ups: > -- 3.1. TLV format > > Type : TBA, Suggested value 10 > > Please add an RFC Editor Note asking the RFC Editor to replace this with the > actual IANA-assigned value. > <Shraddha> Does the RFC Editor Note go as part of this document. Yes, e.g.: **RFC Editor: Please replace above TBA with the actual IANA-assigned value. > -- 4.5. Explicit routing policy The discussion of this example appears to warrant revision to reflect the preference vs. prohibition discussion around Major Issue [1]. Thanks, --David > -----Original Message----- > From: Shraddha Hegde [mailto:shraddha@juniper.net] > Sent: Wednesday, October 07, 2015 3:08 AM > To: Black, David; Rob Shakir; as@cisco.com; bruno.decraene@orange.com; ops- > dir@ietf.org; General Area Review Team (gen-art@ietf.org); > lizhenbin@huawei.com > Cc: acee@cisco.com; ospf@ietf.org; ietf@ietf.org > Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 > > David, > > Thanks a lot for your detailed review and comments. > > Here are the details of responses. I have also attached the updated document. [... snip ...] > --- Nits/editorial comments: ---- > > -- 1. Introduction > > The Abstract says that the tags are for "route and path selection"; the > Introduction should > > also say that. Suggestion - at the end of this sentence in the first > paragraph: > > It is useful to assign a per-node administrative tag to a router in > the OSPF domain and use it as an attribute associated with the node. > > add the text "for route and path selection". This will help with the second > sentence in > > the second paragraph: > > <Shraddha>Modified as per suggestion. > > Path selection is a functional set > which applies both to TE and non-TE applications and hence new TLV > for carrying per-node administrative tags is included in Router > Information LSA [RFC4970] . > > If "path selection" and "functional set" are specific terms with specialized > meaning in > > OSPF context, that sentence is fine as-is, otherwise it would read better if > it began with: > > Route and path selection functionality applies to both ... > > <Shraddha> Modified as per suggestion. > > This document provides mechanisms to advertise per-node administrative > tags in OSPF for route and path selection. Route and path selection > functionality applies > > to > both to TE and non-TE applications and hence new TLV for carrying per-node > administrative tags is included in Router Information LSA ... > > > > -- 3.1. TLV format > > Type : TBA, Suggested value 10 > > Please add an RFC Editor Note asking the RFC Editor to replace this with the > actual IANA- > > assigned value. > <Shraddha> Does the RFC Editor Note go as part of this document. > > -- 3.2. Elements of procedure > > While it's obvious that tag usage should be confined to the administrative > domain that > > understands the tag, it's worth stating. At the end of this > sentence: > > Interpretation of tag values is specific to the administrative domain > of a particular network operator. > > I'd suggest adding: > > , and hence tag values SHOULD NOT be propagated outside the > administrative domain to which they apply. > > <Shraddha> Modified as per suggestion > > -- 4.4. Mobile back-haul network service deployment > > Please expand "eNodeB" acronym on first use. > > <Shraddha> Added > > -- 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. > - The link from the left R node to the left T node does not have a > link weight > - 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? > > Also: "explicitly routed policies" -> "explicit routing policies" > > <Shraddha> It's probably not intended. > Bruno, can you pls confirm? > > 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. > > - 5. Security considerations > > I'd add discussion that advertisement of tag values for one administrative > domain into > > another risks misinterpretation of the tag values (if the two domains have > assigned > > different meanings to the same values), which may have undesirable and > unanticipated side > > effects. > > <Shraddha> Added this point to security considerations. > > In addition, injection of tag values from the outside (e.g., forge OSPF > traffic that > > appears to be from a node in the domain and carries administrative tag values) > is at least > > a possible denial-of-service attack vector, and could also be used for more > nefarious > > purposes (e.g., reroute otherwise unobservable [to the attacker] VPN traffic > via a route > > where the attacker can observe it). > > <Shraddha> In the absence of authentication, such attacks are possible on > existing > OSPF implementations and I don't think it's a new risk added by > this extension. > > > idnits 2.13.02 did not find any nits. > > ---- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---- > > A.1.2. Has installation and initial setup been discussed? > A.1.5. Has the impact on network operation been discussed? > A.1.6. Have suggestions for verifying correct operation been discussed? > > No - given the impact that these tags could have on route and path > computation, likely implementations will be powerful "guns" > with which network operators can readily shoot themselves > in far more than just their "feet." These > considerations would have to be documented based on the > specific uses made of these tags by specific implementations > and deployments. All of that appears to be outside the scope > of this draft. > > A.1.7. Has management interoperability been discussed? > > No - at a minimum, reporting of tag values ought to be defined > via an OSPF MIB extension or analogous functionality. > This is minor issue [D]. > > A.1.8. Are there fault or threshold conditions that should be reported? > > Yes, but they're implementation-specific - see response to > A.1.[2,5,6] above. > > A.2. Management Considerations > Do you anticipate any manageability issues with the specification? > > Yes, manageability has been largely ignored. > > A.3. Documentation > > Is an operational considerations and/or manageability section part of > the document? > > No. > > Does the proposed protocol have a significant operational impact on > the Internet? > > Yes, the anticipated uses will. > > Is there proof of implementation and/or operational experience? > > Nothing was stated in the draft or shepherd write-up. > > As an OPS-Dir member, I'm concerned by the above RFC 5706 answers, and in > particular > > treating all operational issues as vendor- and/or operator-specific. One > possible > > alternative would be to scope the draft down to interoperably specify what's > needed for > > LFA, as indicated by this answer from the Shepherd write-up: > > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > There is consensus from the WG and others outside the WG that > this document can progress. It complements work done on LFA > manageability in the RTG Working Group. > > Another alternative could be Experimental RFC status for the full tag > mechanism (e.g., to > > figure out what it'll be used for in practice, how and why) rather than > Proposed Standard. > > This is major issue [1]. > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, October 07, 2015 4:41 AM > To: Rob Shakir <rjs@rob.sh>; as@cisco.com; bruno.decraene@orange.com; ops- > dir@ietf.org; Shraddha Hegde <shraddha@juniper.net>; General Area Review Team > (gen-art@ietf.org) <gen-art@ietf.org>; lizhenbin@huawei.com > Cc: acee@cisco.com; ospf@ietf.org; ietf@ietf.org; Black, David > <david.black@emc.com> > Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 > > Rob, > > I think something needs to be said on use of tags for preference in route > selection vs. prohibition on use of routes, e.g., as Section 4.5 starts out > with a discussion of preference and then supplies two example policies that > are prohibitions. > > While Section 4.5 appears to need some attention, that seems to be a bit late > in the draft to cover this topic - perhaps this would be fodder for an > "Operational Considerations" section, as suggested in my reply to Bruno. > That could include a statement that route preference policies are a less risky > use of tags by comparison to route prohibition policies. > > Now that I have a better idea of what this draft is intended for, please > ignore my suggestions to scope it to LFA or make it Experimental. > > Thanks, > --David > > > -----Original Message----- > > From: Rob Shakir [mailto:rjs@rob.sh] > > Sent: Tuesday, October 06, 2015 1:22 PM > > To: as@cisco.com; bruno.decraene@orange.com; Black, David; > > ops-dir@ietf.org; shraddha@juniper.net; General Area Review Team > > (gen-art@ietf.org); lizhenbin@huawei.com > > Cc: acee@cisco.com; ospf@ietf.org; Black, David; ietf@ietf.org > > Subject: RE: Gen-ART and OPS-Dir review of > > draft-ietf-ospf-node-admin-tag-06 > > > > > > On October 6, 2015 at 17:46:41, Black, David (david.black@emc.com) wrote: > > > Rob, > > > > > > > Given that we are really selecting candidates from within a set of > > > > paths > > that > > > > have already been selected by OSPF as valid, and usable - then I’m > > > > not > > sure > > > > that I can understand the logic behind this sentence from your review: > > "There > > > > appears to be more than enough enabled by this draft to wreak > > > > serious operational havoc”. > > > > > > Perhaps, I'm not understanding something, but I thought I saw an > > unreachability > > > problem in the example in Section 4.5/Figure 3: > > > > > > - 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? > > > > > > Was that a mistake, and at least one path from the leftmost pair of > > > A nodes to the I nodes will be selected despite that "explicitly routed > policy”? > > > > If the operator chooses to deny prefixes being installed in the RIB > > based on these tags, then yes, they could end up with unreachability > > problems. However, an operator can do this today with any routing > > policy (a number of implementations already have inbound route > > filtering) - we should not prevent this kind of mechanism based on the > > fact that an erroneous config might be problematic. > > > > In the case that the operator *preferences* things based on the tags, > > then this would not be an unreachability problem - OSPF would still > > correctly determine that there is a path between all nodes in the > > pictured network - and this would be installed in the RIB as per normal > operation. > > > > (My memory is not 100% clear on whether this is intended as part of > > the example, if it is, then the text should be clarified I agree.) > > > > Kind regards, > > r.
- Re: [OSPF] Gen-ART and OPS-Dir review of draft-ie… Black, David
- Re: [OSPF] Gen-ART and OPS-Dir review of draft-ie… Shraddha Hegde