Subject: Re: [Isis-wg] RE: Comments on <draft-ietf-isis-admin-tages-01.txt>

From: Alex Zinin <[email-masked]>
Date: Mon, 2 Jun 2003 18:22:56 -0700

Tony, Acee, et al.

I think I should clarify some points here, specifically what I am
and am not concerned with and why.

What I do NOT have a problem with (non-issues):

NI-1. The opaque nature of a route tag as an integer attached
      to a route

NI-2. Presence of a 32-bit and a 64-bit tag simultaneously if
      there is a real reason for this.

NI-3. Even more than one tag, as long as they are used as _tags_,
      though I can't see how more than 2 or 3 tags would be
      useful.

However, what concerns me is (issues with discussions, please
feel free to comment):

I-1. Tag TLVs introduced as any-size opaque transport containers,
     such inflatable "goodie-bags" with practically no internal
     structure (except for n x 32, or n x 64) where one can find
     tags, but also "all kind of nice proprietary things".

     Is there a risk that these TLVs will be used to carry "stuff"
     around? Reviewing the thread, seems that Acee, Tony P. and I
     agree that this is possible:

        "...yes, you could send in 64 bit tags Finnegan's Wake up to
        couple hundred bytes per prefix if you really want to..."

     What's the risk that this will happen? What is the risk that more
     than one vendor will do that? Is this dangerous? Are we going to
     see collisions among vendors in the field? Plus all arguments we
     have seen against vendor-specific extensions during the
     discussion on experimental TLVs are applicable (issues with
     interop, security, changes in proto dynamics, lack of community
     review, etc.)

     It seems that the WG needs to consider these arguments.

I-2. The problem of distributing 2547-related attributes addressed
     by introduction of the n x 64-bit opaque TLV, called 'tag'.
     Why are we overloading the notion of tag from the very beginning?
     Why not have a separate TLV and a proper spec for this?

     This goes hand in hand with the question of why we need another
     tag. If we assume that the right answer to transportation of the
     2547 attributes is a separate TLV with a proper specification of
     what is put there and how to act on it, then we need to answer
     the question "do we need the second tag?" If we read the draft as
     it stands, with the main application being route "color" and
     control over prefix distribution, the second tag does not seem
     necessary.

     Also, the size of the tag (8 octets) raises the risk of "stuff"
     being put into it, though it is admittedly much lower than the
     risk introduced by I-1
     
To comment on some points Tony P. brought up (those not implicitly
addressed above):

1. Why we should know what every tag means?

   I don't believe we should (see NI-1).

   On the other hand, if the document intends to say that one of
   the applications of the tag is to control route distribution,
   it should request that compliant implementations support
   tag-based prefix filtering. Otherwise compliance to the spec
   will not mean anything to the SP who want to actually control
   prefix distribution.
   
2. What about OSPF Opaque LSAs and BGP Extended Communities?

   It seems to me that the difference between them and the current tag
   proposal is in the level at which opaqueness is introduced and
   presence of the internal structure.

   More specifically, before Opaque LSAs were introduced, each new LSA
   type required modification of OSPF SW. Opaque LSAs abstract
   transport details of LSA flooding from the description of LSA
   payload. This helps to avoid having to modify the SW every time a
   new LSA is introduced. (However, each Opaque LSA type needs to be
   registered by IANA through the OSPF WG, which outlaws just grabbing
   an LSA to distribute proprietary stuff.) ISIS already has this
   level of opaqueness through the notion of TLVs.

   Regular BGP communities (RFC1997) are constructed as a set of one
   or more 32-bit values, which seems very close to the description of
   the 32-bit tag TLV in the draft. The difference is in the fact that
   some internal structure is provided at least for admin assignment,
   and that some values are reserved and defined as well-known, with
   well-defined behavior, which enforces their use as tags.

   Extended communities are also different, since each ext community
   is encoded as Type/Value couple, with internal structure specific
   to a type, sub-types allocated by IANA, and fixed-length values.

I hope this clarifies my concerns and will help the discussion.

Thanks.
Alex

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 03 Jun 2003 12:01:00 +0200

>NI-1. The opaque nature of a route tag as an integer attached
ok

>      there is a real reason for this.
the reason may be existing implementaions and/or deployment.

>      though I can't see how more than 2 or 3 tags would be
you don't have to, people will find it out themselves or othrewise there
will be
never more than 3 tags around.

>     interop, security, changes in proto dynamics, lack of community
not again. There are plenty of things in OSPF/ISIS I can misuse as
'hidden communicaiton
channel'. And we agreed that even if SPF is influenced by this tag, you
can only blackhole.
Yes, the possibilites to kill oneself
deserves a mention in the draft but otherwise it's just a
pseudo-exercise in
'home-protocol-security'. You 're not protecting anyone from anything by
restricting
everyting to a single 32 bits tag.

>     Why not have a separate TLV and a proper spec for this?
Yes, we can have another draft, taking another sub-TLV point
specifically 2547.
What's the difference of that beside having some additional encoding
rules that makes no
difference in deployment behavior ? Actually, the more I think about it,
the more
I come to the conclusion that we should just pick up the EXTCOMM structure
for those 64-bit tags and reserve the same LOW types for the same purposes.

>     being put into it, though it is admittedly much lower than the
what 'risks' of what 'stuff' and what 'lower risk' ?
I hope you don't start to argue in such vague terms without any
hard data to back it up. Otherwise I fear the next draft we discuss
will bear the danger
of weapons of mass desctruction. Sorry for the sarcasm but this is
really not
going anywhere fast.

>   I don't believe we should (see NI-1).
agreed, however if everybody wants everybody interoperating on a
specific tag
value, a draft/RFC will be almost a must.

>   will not mean anything to the SP who want to actually control
not again, you can't force people to implement node-specific things.
Maybe they have
high-end nodes that allow policies and low-end that don't. Stop trying
to mandate the
internals of implementations.

>   to a type, sub-types allocated by IANA, and fixed-length values.
ok, so let's make the 64bits just like EXTCOMMs

    - tony

---

From: Alex Zinin <[email-masked]>
Date: Tue, 3 Jun 2003 16:23:26 -0700

Tuesday, June 3, 2003, 3:01:00 AM, Tony Przygienda wrote:
...
> specifically 2547. What's the difference of that beside having some
> additional encoding rules that makes no difference in deployment
> behavior ?

The difference with a non-structured tag would be two-fold:

1. Separate sub-TLV wouldn't be reused for other purposes

2. Its contents and associated router behavior would be clearly
   documented.

> Actually, the more I think about it, the more I come to
> the conclusion that we should just pick up the EXTCOMM structure for
> those 64-bit tags and reserve the same LOW types for the same
> purposes.

Introducing stricture inside the tag and reserving a value for the
2547 application would have the same effect as a separate sub-TLV.

> specific tag value, a draft/RFC will be almost a must.

Agreed.

> Maybe they have high-end nodes that allow policies and low-end that
> don't. Stop trying to mandate the internals of implementations.

I don't know why you are talking about implementation internals here,
and it is interesting that I have to argue this again, while we agreed
on this point before:

Alex Zinin wrote:
>Here's my thinking here.
>
>The title of the document:
>
>  "A Policy Control Mechanism in IS-IS Using Administrative Tags"
>
>The abstract says:
>
>  "This document describes an extension to the IS-IS protocol to add
>   operational capabilities that allow for ease of management and
>   control over IP prefix distribution within an IS-IS domain.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ...
>
>   This extension will provide operators with a mechanism to control IP
>                                                ^^^^^^^^^^^^^^^^^^^^^^^
>   prefix distribution throughout multi-level IS-IS domains.
>   ^^^^^^^^^^^^^^^^^^^
>   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."
>
>and one can definitely feel that filtering at the area boundaries is
>one of the major applications of this TLV.
>
>However, because the document requests the compliant implementations
>to only be able to insert the tag, but not filter using it at the
>L1/L2 IS'es, an operator cannot expect all compliant implementations
>to be useful for this function, i.e., they will need to ask if
>functions outside the scope of this document are supported by specific
>vendors, go into details of how they do that to make sure different
>implementations can work together in a consistent way. Do you see what
>I mean here?

If you guys don't expect compliant implementations to actually be able
'control IP prefix distribution', then don't confuse the reader and
remove hints on it in the text.

If, on the other hand, SPs really want implementations of this
document to be any more useful in prefix control than just flooding
the TLV and displaying the value in the show command, then something
like 'MUST support filtering on boundaries' would make sense in the
document.

Alex