Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - Editorial comments and nits

Shraddha Hegde <shraddha@juniper.net> Thu, 08 October 2015 12:04 UTC

Return-Path: <shraddha@juniper.net>
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 DD3681B32EC; Thu, 8 Oct 2015 05:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 zid8XoQ2oEal; Thu, 8 Oct 2015 05:04:25 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2A51B32ED; Thu, 8 Oct 2015 05:04:24 -0700 (PDT)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by BY1PR0501MB1384.namprd05.prod.outlook.com (10.160.107.142) with Microsoft SMTP Server (TLS) id 15.1.286.20; Thu, 8 Oct 2015 12:04:22 +0000
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) with mapi id 15.01.0286.019; Thu, 8 Oct 2015 12:04:22 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Black, David" <david.black@emc.com>, 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+jq58TPOOmx2JnY0dfAAsdQ5A
Date: Thu, 8 Oct 2015 12:04:22 +0000
Message-ID: <BY1PR0501MB1381991CF9BD55CA242AC594D5350@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <CE03DB3D7B45C245BCA0D24327794936166B2823@MX104CL02.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936166B2823@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net;
x-originating-ip: [116.197.184.14]
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1384; 5:/H/EEgAUpM2Z2XkfwBSLy7xRH8vbUO/cxVJgxd6WP4F7cJAMpUEk8cnjVfsVU1LaCTXqXCD/HurVOi3hI+7iRLUnQVXSQrTbXkifejQLuOpYmgxNIImjrTFShHfIxOr+Llht837bV72D3JRw4/iFeQ==; 24:GkM3YFeMz+4+XklAbQU56VGMY9U9COA0JSK1OGFxQYT/Q1i+5hU8AV/3lBjIp1QyMfkKgBYvHVkxXHXdPAYh95jhV81fKwk66W0aMR37fAM=; 20:4qsnkWl37fh/NgqtFLckO0MHG1JXIOxdIRMKfy00oZByV6MVCJN0axQyRitA88x/PbihI3GlZP/v0ETUuPYrrA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1384;
x-microsoft-antispam-prvs: <BY1PR0501MB138429B05CD5FE8A12EA8A6FD5350@BY1PR0501MB1384.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:BY1PR0501MB1384; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1384;
x-forefront-prvs: 0723A02764
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(189002)(199003)(71364002)(164054003)(5008740100001)(64706001)(40100003)(99286002)(5890100001)(2501003)(92566002)(76576001)(189998001)(74316001)(46102003)(5004730100002)(230783001)(11100500001)(19580395003)(5007970100001)(19580405001)(81156007)(2900100001)(10400500002)(102836002)(5003600100002)(77096005)(87936001)(97736004)(5001770100001)(101416001)(122556002)(105586002)(5001960100002)(33656002)(2950100001)(2201001)(76176999)(50986999)(54356999)(106356001)(86362001)(66066001)(5002640100001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1384; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2015 12:04:22.3119 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1384
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/nO6M-MVkDhclroOQwXaG1QDvzC4>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "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: Thu, 08 Oct 2015 12:04:29 -0000

> -- 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.

<Shraddha> Done.


> -- 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].

<Shraddha> Request Bruno to update this section once we close on all other comments.


Rgds
Shraddha
-----Original Message-----
From: Black, David [mailto:david.black@emc.com] 
Sent: Wednesday, October 07, 2015 8:20 PM
To: Shraddha Hegde <shraddha@juniper.net>et>; Rob Shakir <rjs@rob.sh>sh>; as@cisco.com; bruno.decraene@orange.com; ops-dir@ietf.org; General Area Review Team (gen-art@ietf.org) <gen-art@ietf.org>rg>; 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 - Editorial comments and nits

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>sh>; as@cisco.com; bruno.decraene@orange.com; 
> ops- dir@ietf.org; Shraddha Hegde <shraddha@juniper.net>et>; General Area 
> Review Team
> (gen-art@ietf.org) <gen-art@ietf.org>rg>; 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.