A Policy Control Mechanism in IS-IS Using Administrative Tags
draft-ietf-isis-admin-tags-04

[Ballot 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.

[Ballot comment]
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.

[Ballot discuss]
From the Abstract:

        Additionally, the information
        can be placed in LSPs that have TLVs as yet undefined, if this
        information is used to convey the same meaning in these future TLVs
        as it is used in the currently defined TLVs.

I found this sentence to be a bit out of place as it refers to things that do not yet exist. Is there some reason that this needs to be in the Abstract?

In section 2.1 and 2.2:

        An implementation MAY consider only one of the encoded tags, in which
        case the first encoded tag MUST be considered.

It seems odd to allow an implementation to simply ignore additional tags in a given TLV, with no real indication of when or why this might be so. Can I get more reasoning as to why this is expressly allowed?

[Ballot discuss]
From the Abstract:

        Additionally, the information
        can be placed in LSPs that have TLVs as yet undefined, if this
        information is used to convey the same meaning in these future TLVs
        as it is used in the currently defined TLVs.

I found this sentence to be a bit out of place as it refers to things that do not yet exist. Is there some reason that this needs to be in the Abstract? Shouldn't it really be up to future TLV definitions to decide if they want to normatively reference what is defined in this document?

In section 2.1 and 2.2:

        An implementation MAY consider only one of the encoded tags, in which
        case the first encoded tag MUST be considered.

It seems odd to allow an implementation to simply ignore additional tags in a given TLV, with no real indication of when or why this might be so. Can I get more reasoning as to why this is expressly allowed?

[Ballot discuss]
From the Abstract:

        Additionally, the information
        can be placed in LSPs that have TLVs as yet undefined, if this
        information is used to convey the same meaning in these future TLVs
        as it is used in the currently defined TLVs.

I found this sentence to be confusing as it refers to things that do not yet exist. Is there some reason that this needs to be in the Abstract?

In Section 1:

          As of this writing no sub-TLVs have been defined; however, this draft
        proposes 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237
        that may be used to carry administrative information about an IP 
        prefix.

Very confusing to say that no sub-TLVs have been defined, and then say that this draft defines two. Could you remove the first part of this sentence?

In section 2.1 and 2.2:

        An implementation MAY consider only one of the encoded tags, in which
        case the first encoded tag MUST be considered.

It seems odd to allow an implementation to simply ignore additional tags in a given TLV, with no real indication of when or why this might be so. Can I get more reasoning as to why this is expressly allowed?

[Ballot discuss]
(This is a discuss only because I believe Abstracts should be very clear)

From the Abstract:

        Additionally, the information
        can be placed in LSPs that have TLVs as yet undefined, if this
        information is used to convey the same meaning in these future TLVs
        as it is used in the currently defined TLVs.

I found this sentence to be confusing as it refers to things that do not yet exist. Is there some reason that this needs to be in the Abstract?

In Section 1:

          As of this writing no sub-TLVs have been defined; however, this draft
        proposes 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237
        that may be used to carry administrative information about an IP 
        prefix.

Very confusing to say that no sub-TLVs have been defined, and then say that this draft defines two. Could you remove the first part of this sentence?

In section 2.1 and 2.2:

        An implementation MAY consider only one of the encoded tags, in which
        case the first encoded tag MUST be considered.

It seems odd to allow an implementation to simply ignore additional tags in a given TLV, with no real indication of when or why this might be so. Can I get more reasoning as to why this is expressly allowed?

[Ballot comment]
- Obsolete Reference: RFC 3667
  - Obsolete Reference: RFC 3668

Has a _ton_ of other idnits, please check with latest version of the tool.

[Ballot discuss]
- Downref: Non-RFC Normative Reference: ref. '1'
  * Downref: Informational Normative Reference: RFC 3784 (ref. '3')
  * Downref: Informational Normative Reference: RFC 2702 (ref. '4')
  * Downref: Informational Normative Reference: RFC 2966 (ref. '5')

[Ballot comment]
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?

[Ballot comment]
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.

IANA Last Call Comments:


Upon approval of this document, the IANA will make the
following changes in "IS-IS TLV Codepoints per [RFC3563]"
registry located at

http://www.iana.org/assignments/isis-tlv-codepoints


Old:
Sub-TLVs for TLV 135
====================

Allocations within this registry require documentation of
the use of the allocated value and approval by the Designated
Expert assigned by the IESG.

Type Description Reference
---- ------------------------- ---------
0-255 unassigned




NEW:
Sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237
====================

Allocations within this registry require documentation of
the use of the allocated value and approval by the Designated
Expert assigned by the IESG.

Type Description Reference
---- ------------------------- ---------
0 unassigned [RFC3784]
1 32-bit Administrative Tag Sub-TLV [RFC-isis-admin-tags]
2 64-bit Administrative Tag Sub-TLV [RFC-isis-admin-tags]
3-255 unassinged

We understand the above to be the only IANA Actions for
this document.

AD-review comments:

Comments:

In order to preserve interoperability with tag-unaware routers, I
think we should add some words saying that the implementations MUST
NOT change their SPF calculation based on the contents of the
introduced TLVs.

Thinking aloud: though the mechanism is inherently opaque, if we want
the implementations claiming their compliance to it to really be
usable for [from the doc] "controlling redistribution between levels
and areas, different routing protocols", should we say that compliant
implementations SHOULD support such filtering? On the one hand,
there's a wide spectrum of applications that can use these tags and we
don't want to say foo and bar are the only ones, on the other hand if
I were deploying this in a multi-vendor environment, I'd likely want
to see a consistent minimal set of features, i.e., not just attaching
a tag, but also executing on it if the router is a L1/L2 or an ASBR.
Did you guys think about this?

What I think is missing in the draft is specification of how multiple
instances of the same sub-TLV should be treated, i.e., I could see
some implementations deciding to merge the tag sets, and some using
just the first (or the last) instance, which would result in interop
issues. Should be spelled out, I think.

A similar, and somewhat more interesting question is about the two
types of tags--32 bits and 64 bits. Since the value spaces for the two
are overlapping, i.e., there's a range {x}, where X can be coded as
both 32 and 64 bits, should the implementations consider the two TLVs
as operating on a single large 64-bit space (with one covering only
half the space, and one covering the whole thing), or on two separate
ones with different sizes. In other words, if my policy says "match
tag 234", should it match both a 32- and a 64-bit tag, or should it
differentiate between the two and operate more in a way of "match
tag-32 234" and "match tag-64 234"? I could see how different
implementations could treat this differently and I could get different
route filtering results given the same input data.

There will also be a question on why do we need a 32-bit tag if we
have a 64-bit one, which could accommodate 32-bit values too.


> 6. Ordering of Tags
>
>    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.  Each tag SHOULD be treated as an
>    autonomous identifier that MAY be used in policy to perform a policy
>    action.  Whether or not tag A preceeds or succeeds tag B SHOULD not
>    change the meaning of the tag set.  However, an implementation MAY
>    wish to preserve tag ordering such that an ordered set of tags has
>    meaning to the local policy.

To preserve tag ordering where? Within the TLV? (a pseudo-question
really, since one shouldn't change someone else's TLV contents)

> 7. A compliant IS-IS implementation:

>    MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or
>    235.

There will be a question on whether attaching both TLV types MUST be
supported by an implementation, or just one of them. I think we need
to say both.

> 10. IANA Considerations
>
>    The authors have chosen "1" as the typecode of the 32-bit
>    Administrative Tag sub-TLV and "2" as the typecode of the 64-bt
>    Administrative Tag SubTLV.  These values must be allocated by IANA.

Change to "This document defines..."?


Nits below:

> 1. Status of this Memo

Shouldn't be numbered

> 2. Abstract

The rfc-ed will not like the references in the abstract,
please remove.

> 5.1. 32-bit Administrative Tag Sub-TLV 1
>
>    The Administrative Tag shall be encoded as one or more 4 octet
>    unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The
>    Administrative Tag Sub-TLV has following structure:
>
>        1 octet of type (value: 1)
>        1 octet of length (value: multiple of 4)
>        one or more instances of 4 octets of administrative tag

Would be great if we had the same format as in RFC1195, or 3373
for consistency. Using IETF format is an option too.

Ditto for 5.2


> 12. References

Please split them to normative and informative like below:

12. Normative References

...
13. Informative References

...

Comments from rtg-dir (Acee):
Comments:

  1. The last sentence of the abstract doesn't make sense. "Additionally,
      the information can be placed in LSPs that have TLVs as yet
      undefined, if this information is used to convey the same
      meaning in these future TLVs as it used in the currently defined
      TLVs". Suggested - "The administrative tag sub-TLVs may be used with
      with future TLVs as long as their semantics are preserved."

  2. Section 5.2 - The value of the type is wrong - it should be 2 rather
      than 1.

  3. Section 6 says the ordering of tags is not significant. However, the
      previous sections (5.1 and 5.2) say that an implementation may only
      consider the first tag.

  4. Section 7 - List the requirements for receiving the new Sub-TLVs in
      this compliance section as well (even if they were stated previously).

  5. Section 8 - The example talks about R2 associating tag 110 with property
      A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with property
      A is adjacent to R1 (which applies to me that R1 originate the prefix).
      Please fix either the example or the figure.

Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt):

  1. The abstract contains references. The documents should be specified
      by name since the abstract can be excerpted.

  2. Line 323 over 72 chars.

    Line 323 length is 74
          Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April

  3. Pages 2, 3, 4, and 5 have over 58 lines.