A Policy Control Mechanism in IS-IS Using Administrative Tags
draft-ietf-isis-admin-tags-04
Discuss
Yes
(Bill Fenner)
(Ross Callon)
No Objection
(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Mark Townsley)
(Ron Bonica)
(Russ Housley)
(Ted Hardie)
Note: This ballot was opened for revision 04 and is now closed.
David Kessens Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2007-02-08)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Ross Callon Former IESG member
(was No Objection)
Yes
Yes
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2007-02-02)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2007-02-05)
Unknown
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2007-02-02)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
(2007-02-07)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown