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

From: "Tony Li" <[email-masked]>
Date: Mon, 2 Jun 2003 21:47:43 -0700

Let me respond to all of Alex's comments at once...

How do I see vendor defined tags being used?  I see them being used
for experimental purposes, for shipping some new functionality before
the implementation is wholly stable.  As with any experimental object,
I would hope that it would eventually be documented and become 
standardized.  Just so we don't have to play proprietary IGP games yet
again.

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

I submit to you that almost any experimental TLV can be used for this
purpose, or any obsolete TLV value, or any hijacked TLV could be used
fairly safely.  So I don't believe that even if you eliminated this
proposal, you would deter anyone from including Finnegan's Wake in the
slightest.  

The issue that I have with using this (or any TLV) for such fun is that
it's basically dishonest and unnecessarily so.  If folks feel the
need to carry A Tale of Two Cities in their IGP, well, I'm not going
to stop them, but please, let's allocate some intelligent and opaque
TLV so that we all realize that this is someone's private sandbox.

That said, that doesn't seem like an issue that should deter this
proposal.

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

Or, why not just explicitly allocate global tag values for 2547
attributes?
I have no issue with this (above and beyond my general distaste for
2547).

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 03 Jun 2003 11:43:28 +0200

>standardized.  Just so we don't have to play proprietary IGP games yet
agreed

>That said, that doesn't seem like an issue that should deter this
agreed

>I have no issue with this (above and beyond my general distaste for

oops, even you, Brutus ;-)

Can  we agree here on e.g.:

    1) let's the 32+64 go, not worth the energy for little damage done.
Decouple the
        two and that's it. Yes, it's tad of more implementation code but
it's better
        than waste 2 years chewing on it. And by then, it's deployed
anyway so you
        end up documenting it no matter what we came up with as 'better'
solution.
    2) introduce 2-3 bits in front of tag to structure it (albeit we
have deployments,
        I think Cisco/JNPR would swallow that one). But, then, how would
we fit
        EXTCOMMs that are 64bits into 64bits ?
    3) Put a section in describing that in misconfiguration and using
the tag for supressing
        prefixes in SPF, blackholes may result.
    3) Put a section in that any tag that's supposed to be understood
globally and influence
        SPF must be brought to the group

thanks 

	- tony

---

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

Tony,

[...]
> Can  we agree here on e.g.:

I would be fine with any approach that the WG agrees on and that
preferably gets rid of the "generic container" problem.

I do think that introducing structure and/or well-know reserved values
solves this problem.

Regarding the two items "3)" below ;) I think there was more to fix
there, but I'll check.

Alex

> Decouple the two and that's it. Yes, it's tad of more implementation
> code but it's better than waste 2 years chewing on it. And by then,
> it's deployed anyway so you end up documenting it no matter what we
> came up with as 'better' solution.

> have deployments, I think Cisco/JNPR would swallow that one). But,
> then, how would we fit EXTCOMMs that are 64bits into 64bits ?

> the tag for supressing prefixes in SPF, blackholes may result.

> globally and influence SPF must be brought to the group

---

From: Alex Zinin <[email-masked]>
Date: Tue, 3 Jun 2003 14:24:42 -0700

Tony,

Thanks for your reply. Below, pls.

> standardized.  Just so we don't have to play proprietary IGP games yet

Experimental would be good.
Vendor-specific for shipping would most probably trigger a similar
discussion we had on the experimental TLVs.

> TLV so that we all realize that this is someone's private sandbox.

Agreed

> That said, that doesn't seem like an issue that should deter this

As long as the issues have been discussed and well-understood.
I like you proposal with some well-defined tags though.

> I have no issue with this (above and beyond my general distaste for

Yes, seems this would work well too.

Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 6 Jun 2003 11:41:48 -0400

> standardized.  Just so we don't have to play proprietary IGP games yet

Is it worth specifying a transitional mechanism to move the ID
out of the "experimental" space into the ietf-consensus numbered
space?

> fairly safely.

My concern has been collision in the numbering space.  In the
BGP extended community experimental numbering space, there is no
guidance as to how you should pick your experimental number.  I haven't
seen vendors providing a knob to set the feature's community number
and thus its possible for two vendors to utilize the same number
and end up causing all sorts of havoc.

I don't disagree with the idea of an experimental space, but it would
be nice to at least talk about namespace collisions and how we
might work around them.

I would also prefer an answer isn't "this hurts", "Don't do that then!".

-- 
Jeff Haas 
NextHop Technologies