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

[Shraddha Hegde <[e-mail]>]

David,

Thanks a lot for your detailed review and comments. 

Here are the details of responses. I have also attached the updated document.

---- Major issues: ----

[1] Operational considerations:  There appears to be more than enough enabled by this draft 

to wreak serious operational havoc, but the draft seems to sidestep all operational topics, 

primarily by treating all usage of tags as vendor- or implementation- specific and trusting 

the vendors and operators not to foul things up.  I'm not sure that's wise.

<Shraddha> Added a new "Operational Considerations" section as suggested in other mail threads on this topic.
-----------------------------------------------------------------------------------------------------



See end of OPS-Dir review below for more on this concern.

--- Minor issues: ----

-- 3.2 Elements of procedure:

[A] I see what look like some underspecified requirements:

   Each tag SHOULD be treated as an independent identifier that MAY be
   used in policy to perform a policy action.

   The administrative tag list within the
   TLV SHOULD be considered an unordered list.

Why are those two not "MUST" requirements?  What happens if either is not done?

<Shraddha> It's perfectly valid for the receiver of the node admin tag to ignore a certain 

tag or set of tags if there are no local policies. I think MUST will be too restrictive 

statement.

--------------------------------------------------------------------------------------------------------------------------

[B] Tag set completeness:

   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.

This paragraph is about processing at that node.  It's easy to misread, as that implication 

is buried in the word "originated" in the last line. 
Suggested change:

	"for the purpose of any computation or processing SHOULD" ->
	"for the purpose of any computation or processing performed
		at that node SHOULD"

Also, it looks like it's acceptable for other nodes to perform such computation or 

processing based on a partial tag set for this node (e.g., when some other node has not 

received all the RI LSAs with all the tags).  That should be stated.

<Shraddha> This is talking about processing at the receiver. Will update as below.


 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 at the receiver SHOULD
   be a superset of node administrative tags from all the TLVs in all
   instances of the RI LSA originated by that node.Receiver MAY perform the processing on 

administrative node tags when only a partial set is receieved but the receiver node MUST 

repeat the computation or processing when the complete set of node administrative tags for 

that node is received.

---------------------------------------------------------------------------------------------------------------------------------
[C] Tag change/removal:

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

Inability to interoperably remove a tag value (e.g., distribute the update that tag X no 

longer applies to node Q) seems like a significant omission, but I'm not a routing expert, 

so I'll defer to the WG's and ADs' judgment on the importance of this.  At a minimum, the 

rationale for not specifying an interoperable tag value removal mechanism ought to be added 

to this document.

<Shraddha> Added the tag updations at the origination.
 
When there is a change or removal of an adminstrative affiliation of a node, the node MUST 

re-originate the RI LSA with the latest set of node administrative tags.
On the receiver, 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 specification.
-----------------------------------------------------------------------------------------------------------------------------------------
 
[D] No management support

From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be defined via an OSPF MIB 

extension or analogous functionality.

<shraddha> I think this should be taken separately as part of OSPF MIB RFC update, which 

will combine multiple features which require new definitions.

Acee, How do we go about this?

-----------------------------------------------------------------------------------------------------------------------------

--- 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:[e-mail]] 
Sent: Wednesday, October 07, 2015 4:41 AM
To: Rob Shakir <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Shraddha Hegde <[e-mail]>; General Area Review Team ([e-mail]) <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; Black, David <[e-mail]>
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:[e-mail]]
> Sent: Tuesday, October 06, 2015 1:22 PM
> To: [e-mail]; [e-mail]; Black, David; 
> [e-mail]; [e-mail]; General Area Review Team 
> ([e-mail]) [e-mail]
> Cc: [e-mail]; [e-mail]; Black, David; [e-mail]
> 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 ([e-mail]) 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.