A Policy Control Mechanism in IS-IS Using Administrative Tags
Note: This ballot was opened for revision 04 and is now closed.
(David Kessens) Discuss
Discuss (2007-02-08 for -)
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.
(Ross Callon) (was No Objection) Yes
(Bill Fenner) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Brian Carpenter) No Objection
Comment (2007-02-02 for -)
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?
(Lars Eggert) (was Discuss) No Objection
- Obsolete Reference: RFC 3667 - Obsolete Reference: RFC 3668 Has a _ton_ of other idnits, please check with latest version of the tool.
(Ted Hardie) No Objection
(Sam Hartman) No Objection
Comment (2007-02-07 for -)
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.
(Russ Housley) No Objection
(Chris Newman) No Objection
(Jon Peterson) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) (was Discuss) No Objection
(David Ward) No Objection
Magnus Westerlund (was Discuss) No Objection
Comment (2007-02-02 for -)
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.