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

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

[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] (This is a discuss only because I believe Abstracts should be very clear) From the Abstract: Additionally, the information can be placed in ...

[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] I very nearly made this a DISCUSS... 1. The example in Fig 1 is not from the range of example addresses. 2. 7 ...

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

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

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

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

...