--- draft-ietf-ospf-node-admin-tag-06.xml.orig	2015-10-09 15:14:43.000000000 -0500
+++ draft-ietf-ospf-node-admin-tag-06.xml	2015-10-09 15:45:02.000000000 -0500
@@ -93,17 +93,17 @@
 <keyword>traffic engineering</keyword>

 <abstract>

 <t> 

-This document describes an extension to OSPF protocol to

+This document describes an extension to the OSPF protocol to

 add an optional operational capability, that allows tagging and grouping of

-the nodes in an OSPF domain. This allows simplification, ease of management and

+the nodes in an OSPF domain. This allows simplification, ease of management, and

 control over route and path selection based on configured policies.

 

-This document describes an extension to OSPF protocol to advertise per-node 

+This document describes an extension to the OSPF protocol to advertise per-node 

 administrative tags. The node-tags can be used to express and apply locally-defined

 network policies which is a very useful operational capability. Node tags may be used either by OSPF 

 itself or by other applications consuming information propagated via OSPF. </t>

 <t>This document describes the protocol extensions to disseminate

-per-node administrative-tags to the OSPFv2 and OSPFv3 protocol. It provides example

+per-node administrative tags to the OSPFv2 and OSPFv3 protocols. It provides example

  use cases of administrative node tags.</t>

 </abstract>

 <note title="Requirements Language">

@@ -118,7 +118,7 @@
 <t> 

 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. The per-node administrative tag can be used in

-variety of applications, for ex:

+variety of applications, for example:

   -  Traffic-engineering applications to provide different path-selection criteria, 

   -  Prefer or prune certain paths in Loop Free Alternate (LFA) backup selection via local policies.</t>

 

@@ -136,12 +136,12 @@
 used to identify a group of nodes in the OSPF domain.

 <vspace blankLines="1" />

 The new TLV defined will be carried within an RI LSA for OSPFV2 and

-OSPFV3. Router information LSA <xref target="RFC4970"/> can have link, area or AS level

-flooding scope. Choosing the flooding scope to flood the group

-tags are defined by the policies and is a local matter.

+OSPFV3. Router information LSA <xref target="RFC4970"/> can have link-, area- or AS-level

+flooding scope. The choice of what scope at which to flood the group tags is

+a matter of local policy.

 <vspace blankLines="1" />

 The TLV specifies one or more administrative tag values. An OSPF

-node advertises the set of groups it is part of in the OSPF domain.

+node advertises the set of groups it is part of in the OSPF domain

 (for example, all PE-nodes are configured with certain tag value,

 all P-nodes are configured with a different tag value in the domain).

 Multiple TLVs MAY be added in same RI-LSA or

@@ -151,12 +151,12 @@
 </section>

 <section title='OSPF per-node administrative tag TLV'>

 <section title='TLV format'>

-<t> <xref target="RFC4970"/>, defines Router Information (RI) LSA which may be used to 

-advertise properties of the originating router. Payload of the RI LSA consists of one or

+<t> <xref target="RFC4970"/>, defines the Router Information (RI) LSA which may be used to 

+advertise properties of the originating router. The payload of the RI LSA consists of one or

 more nested Type/Length/Value (TLV) triplets.

 

 Node administrative tags are advertised in the Node Administrative Tag TLV.

-The format of Node Administrative Tag TLV is:

+The format of the Node Administrative Tag TLV is:

 

 <vspace blankLines="2" />

 <figure anchor="OSPF-Admin-tag-TLV" title="OSPF per-node Administrative Tag TLV">

@@ -184,17 +184,17 @@
 portion in octets and will be a multiple of 4 octets

 dependent on the number of tags advertised.

 <vspace blankLines="1" />

-Value: A sequence of multiple 4 octets defining the

+Value: A sequence of multiple four-octet values defining the

 administrative tags.  At least one tag MUST be carried if

 this TLV is included in the RI-LSA.

 </t>

 </section>

 <section title='Elements of procedure'>

-<t>Meaning of the Node administrative tags is generally

-opaque to OSPF. Router advertising the per-node

+<t>The meaning of the Node administrative tags is generally

+opaque to OSPF. Routers advertising the per-node

 administrative tag (or tags) may be configured to do so

 without knowing (or even explicitly supporting)

-functionality implied by the tag.</t>

+the functionality implied by the tag.</t>

 <t>Interpretation of tag values is specific to the administrative domain of a particular network operator.

 The meaning of a per-node administrative tag is defined by the network local policy

 and is controlled via the configuration. If a receiving node does not

@@ -222,17 +222,17 @@
 Router (ABR) may advertise the same tag in area-scope RI

 LSAs in multiple areas connected to the ABR.</t>

 <t>The per-node administrative tags are not meant to be

-extended by the future OSPF standards. The new OSPF

+extended by future OSPF standards. New OSPF

 extensions MUST NOT require use of per-node administrative

 tags or define well-known tag values. Node administrative tags

 are for generic use and do not require IANA registry.

-The future OSPF extensions requiring well known values MAY

+Future OSPF extensions requiring well known values MAY

 define their own data signalling tailored to the needs of the

-feature or MAY use capability TLV as defined in

+feature or MAY use the capability TLV as defined in

 <xref target="RFC4970"/>. </t>

 <t>Being part of the RI LSA, the per-node administrative tag

 TLV must be reasonably small and stable. In particular,

-but not limited to, implementations supporting the per-node

+but not limited to, implementations supporting per-node

 administrative tags MUST NOT tie advertised tags to

 changes in the network topology (both within and outside

 the OSPF domain) or reachability of routes.</t>

@@ -240,20 +240,20 @@
 <t> Multiple node administrative tag TLVs MAY appear in an RI LSA or

 multiple node administrative tag TLVs MAY be contained in different instances of the 

 RI LSA. The node administrative tags associated with a node for the purpose of any computation or processing SHOULD be a superset of 

-node administrative tags from all the TLVs in all instances of the RI LSA originated by that node.</t>

+node administrative tags from all the TLVs in all instances of RI LSAs originated by that node.</t>

 <t>When there is a change in the node administrative tag TLV or removal/addition of a

-TLV in any instance of the RI-LSA, implementations MUST take appropriate measures to update its state according to the

-changed set of tags. Exact actions depend on features working with administrative tags and is outside of scope of this

+TLV in any instance of an RI-LSA, implementations MUST take appropriate measures to update their state according to the

+changed set of tags. The exact actions needed depend on features working with administrative tags and is outside of scope of this

 specification.

 </t>

 </section>

 </section>

 <section title='Applications'>

 <t>This section lists several examples of how implementations

-might use the Node administrative tags. These examples are

-given only to demonstrate generic usefulness of the router

-tagging mechanism. Implementation supporting this

-specification is not required to implement any of the use

+might use the per-node administrative tags. These examples are

+given only to demonstrate the generic usefulness of the router

+tagging mechanism. Implementations supporting this

+specification are not required to implement any of these use

 cases. It is also worth noting that in some described use

 cases routers configured to advertise tags help other routers

 in their calculations but do not themselves implement the

@@ -261,12 +261,12 @@
 <section title='Service auto-discovery'>

 <t>

 <vspace blankLines="1"/>

-Router tagging may be used to automatically discover

+Router tagging may be used to automatically discover a

 group of routers sharing a particular service.

 <vspace blankLines="1"/>

-For example, service provider might desire to establish

-full mesh of MPLS TE tunnels between all PE routers in

-the area of MPLS VPN network. Marking all PE routers with

+For example, a service provider might desire to establish

+a full mesh of MPLS TE tunnels between all PE routers in

+the area of the MPLS VPN network. Marking all PE routers with

 a tag and configuring devices with a policy to create

 MPLS TE tunnels to all other devices advertising this tag

 will automate maintenance of the full mesh. When new PE

@@ -286,13 +286,13 @@
 concerns.

 <vspace blankLines="1"/>

 One of the proposed refinements is to be able to group

-the nodes in IGP domain with administrative tags and

+the nodes in an IGP domain with administrative tags and

 engineer the LFA based on configured policies.

 <list style="format (%c)" hangIndent="4">

 <t>Administrative limitation of LFA scope

 <vspace blankLines="1"/>

 Service provider access infrastructure is frequently

-designed in layered approach with each layer of

+designed in a layered approach with each layer of

 devices serving different purposes and thus having

 different hardware capabilities and configured

 software features. When LFA repair paths are being

@@ -305,7 +305,7 @@
 be desirable for a Distribution device to compute LFA

 only via Distribution or Core devices but not via

 Access devices. This may be due to features enabled

-on Access routers; due to capacity limitations or due

+on Access routers, due to capacity limitations or due

 to the security requirements. Managing such a policy

 via configuration of the router computing LFA is

 cumbersome and error prone.

@@ -314,20 +314,20 @@
 assign a tag to each layer and implement LFA policy

 of computing LFA repair paths only via neighbors

 which advertise the Core or Distribution tag. This

-requires minimal per-node configuration and network

+requires minimal per-node configuration and the network

 automatically adapts when new links or routers are

 added.

 </t>

 <t>LFA calculation optimization

 <vspace blankLines="1"/>

 Calculation of LFA paths may require significant

-resources of the router. One execution of Dijkstra

+resources of the router. One execution of Dijkstra's

 algorithm is required for each neighbor eligible to

-become next hop of repair paths. Thus a router with a

+become the next hop of repair paths. Thus, a router with a

 few hundreds of neighbors may need to execute the

 algorithm hundreds of times before the best (or even

 valid) repair path is found. Manually excluding from

-the calculation neighbors which are known to provide

+the calculation neighbors that are known to provide

 no valid LFA (such as single-connected routers) may

 significantly reduce number of Dijkstra algorithm

 runs.

@@ -345,22 +345,22 @@
 <vspace blankLines="1"/>

 <xref target="RFC7490"/> defined a

 method of tunnelling traffic after connected link failure

-to extend the basic LFA coverage and algorithm to find

+to extend the basic LFA coverage and an algorithm to find

 tunnel tail-end routers fitting LFA requirement. In most

-cases proposed algorithm finds more than one candidate

-tail-end router. In real life network it may be desirable

+cases the proposed algorithm finds more than one candidate

+tail-end router. In real-life networks it may be desirable

 to exclude some nodes from the list of candidates based

 on the local policy. This may be either due to known

-limitations of the node (the router does not accept targeted

+limitations of the node (the router does not accept the targeted

 LDP sessions required to implement Remote LFA tunnelling)

 or due to administrative requirements (for example, it

-may be desirable to choose tail-end router among

+may be desirable to choose the tail-end router among

 co-located devices).

 <vspace blankLines="1"/>

-The Node administrative tag delivers simple and scalable

+The Node administrative tag delivers a simple and scalable

 solution. Remote LFA can be configured with a policy to

 accept during the tail-end router calculation as

-candidates only routers advertising certain tag. Tagging

+candidates only routers advertising a certain tag. Tagging

 routers allows to both exclude nodes not capable of

 serving as Remote LFA tunnel tail-ends and to define a

 region from which tail-end router must be selected.

@@ -369,8 +369,8 @@
 <section title='Mobile back-haul network service deployment'>

 <t>

 <vspace blankLines="1"/>

-The topology of mobile back-haul network usually adopts ring topology

-to save fibre resource and it is divided into the aggregate network and

+Mobile back-haul networks usually adopt a ring topology

+to save fibre resources; it is usually divided into the aggregate network and

 the access network. Cell Site Gateways(CSGs) connects the eNodeBs and

 RNC(Radio Network Controller) Site Gateways(RSGs) connects the RNCs.

 The mobile traffic is transported from CSGs to RSGs. The network takes

@@ -408,7 +408,7 @@
 <vspace blankLines="1"/>

 A typical mobile back-haul network with access rings and aggregate

 links is shown in figure above. The mobile back-haul networks deploy

-traffic engineering due to the strict Service Level Agreements(SLA).

+traffic engineering due to strict Service Level Agreements(SLA).

 The TE paths may have additional constraints to avoid passing via different

 access rings or to get completely disjoint backup TE paths. The mobile back-haul

 networks towards the access side change frequently due to the growing mobile

@@ -422,9 +422,9 @@
 <section title='Explicit routing policy'>

 <t>

 <vspace blankLines="1"/>

-Partially meshed network provides multiple paths between any two nodes in the network.

+A partially meshed network provides multiple paths between any two nodes in the network.

 In a data centre environment, the topology is usually highly symmetric with many/all

-paths having equal cost. In a long distance network, this is usually less the case for

+paths having equal cost. In a long distance network, this is usually less the case, for

 a variety of reasons (e.g. historic, fibre availability constraints, different distances

 between transit nodes, different roles ...). Hence between a given source and destination,

 a path is typically preferred over the others, while between the same source and another

@@ -520,4 +520,4 @@
 <?rfc include="reference.I-D.ietf-rtgwg-lfa-manageability"?>

 </references>

 </back>

-</rfc>
\ No newline at end of file
+</rfc>