A Policy Control Mechanism in IS-IS Using Administrative Tags
draft-ietf-isis-admin-tags-04
Discuss
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert (was Discuss) No Objection
(David Kessens; former steering group member) Discuss
In section '2. Sub-TLV Additions ':
The methods for which their use is employed is beyond the scope of
this document and left to the implementer and/or operator.
We are not required to have a complete operational description, but
I do believe that there should be a few example use cases that the
authors envision what this option can be/should be used for.
An implementation MAY consider only one of the encoded tags, in which
case the first encoded tag MUST be considered.
What is the motivation for this ? I don't see why the first tag is more
important than the next one. I also wonder why the 'MAY' is useful in the
first place.
Note that section '3. Ordering of Tags' says:
The semantics of the tag order are implementation-dependent. That
is, there is no implied meaning to the ordering of the tags that
indicates a certain operation or set of operations need be performed
based on the order of the tags.
Why is the following not a 'MUST':
However, an implementation MAY
wish to preserve tag ordering such that an ordered set of tags has
meaning to the local policy.
This seems a recipe for problems for operators with multi-vendor networks
and I don't see a reason why the spec allows for this flexibility without
a real benefit.
I don't why a 'SHOULD' is used instead of a 'MUST':
If an
implementation needs to change tag values, for example, at an area
boundary, then the TLV(s) SHOULD be copied to the newly generated
Level-1 or Level-2 LSP at which point, the contents of the SubTLV(s)
MAY change as dictated by the policy action. In the event that no
change is required, the SubTLV(s) SHOULD be copied in order into the
new LSP, such that ordering is preserved.
In section '5. Operations':
There is no discussion on how compliant and non-compliant routers are
supposed to interact.
Otherwise, this draft is well written and easy to understand.
(Bill Fenner; former steering group member) Yes
(Ross Callon; former steering group member) (was No Objection) Yes
(Brian Carpenter; former steering group member) No Objection
I very nearly made this a DISCUSS...
1. The example in Fig 1 is not from the range of example addresses.
2.
7. IANA Considerations
The authors have chosen "1" as the type code of the 32-bits
Administrative Tag Sub-TLV and "2" as the type code of the 64-bits
Administrative Tag Sub-TLV. These values must be allocated by IANA.
We normally talk about suggested values, not "must", and does this need
a new registry?
(Chris Newman; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
The security consideration sections seems incredible thin. Aren't there risks with someone tapping this information from within the network. What effect would that have? I think that should be described.
(Mark Townsley; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
I think the semantics specified by this draft are incredibly thin about how tags can be set from BGP extended communities, how tags can be used, etc. I think that there are not really sufficient semantics for a reasonable assurance that two implementation make sufficiently similar uses of tags that you can use them on the same network. I consider that a problem, but there's just enough there that I'm filing a no-obj.
(Ted Hardie; former steering group member) No Objection