Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt

From: Kireeti Kompella <[email-masked]>
Date: Mon, 14 Jun 2004 17:10:14 -0700 (PDT)

On Wed, 12 May 2004 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.
>
> 	Title		: TLV for Experimental Use
> 	Author(s)	: P. Christian
> 	Filename	: draft-ietf-isis-experimental-tlv-03.txt
> 	Pages		: 6
> 	Date		: 2004-5-6
>
> This document defines a TLV that may be used by any individual,
> company or other organisation for experimental extensions to the
> IS-IS routing protocol, and defines the format of the TLV.

I have a request, if I may.

Either change the "discriminator" from an OUI to an SNMP Enterprise
Code (http://www.iana.org/assignments/enterprise-numbers),

OR

Have a parallel experimental TLV (251?) that uses Enterprise Codes.

Everything else is exactly the same, except (of course) the Enterprise
Code is 4 octets.

Thanks,
Kireeti.
-------

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Wed, 16 Jun 2004 10:27:06 -0400

It would be a bad idea to change the current interpretation of 
this TLV, since it could lead to ambiguities.  It might also
be a bad idea to assign a new TLV number for this; how many
different numbering plans are there we might be asked to
accommodate in the future?

One possibility, albeit "wasting" 3 octets pre TLV, would be to
assign an org ID for this purpose (".  We could also choose
a value with the "local" bit set, which would never be
assigned as a valid OUI.  We could assign any number of these
"local OUIs" to identify any future numbering plans.

The alternative would be to choose a new TLV value, where the
first octet of the value identifies the numbering plan, something
like this:

  0 - OUI (treat TLV as synonymous to original TLV and same OUI)
  1 - SNMP Enterprise ID

This would provide a more concise format for future numbering
plans.

First we'd need to find out if there's enough support for this
idea to justify the change.  I have no opinion on that.

Regards,
Jeff

---

From: Philip Christian <[email-masked]>
Date: Thu, 17 Jun 2004 10:52:39 +0100

Also someone (such as Juniper :-) ) could even donate an OUI the use of 
which would indicate that the next four bytes is an SNMP ID.

In hindsight maybe I should have put an extra byte before the OUI to 
indicate that OUI is the mechanism.

I suppose that we could write a new draft that goes

                                             No. of Octets
              +---------------------------+
              |        CODE =250          |      1
              +---------------------------+
              |       LENGTH =n+4         |      1
              +---------------------------+
              |         11000001          |      1
              +---------------------------+
              |           OUI             |      3
              +---------------------------+
              |           DATA            |      n
              +---------------------------+

                                             No. of Octets
              +---------------------------+
              |        CODE =250          |      1
              +---------------------------+
              |       LENGTH =n+5       |      1
              +---------------------------+
              |         11000010          |      1
              +---------------------------+
              |         SNMP ID           |      4
              +---------------------------+
              |           DATA            |      n
              +---------------------------+

This would not clash with the current draft provided that no-one has used 
an OUI with both the multicast and the locally assigned bit set.  No-one 
would do that, would they ?

It would give us 64 ways of defining indicators in the future.

Regards, Philip

At 10:27 16/06/2004 -0400, Jeff Learman wrote:

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.690 / Virus Database: 451 - Release Date: 22/05/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.690 / Virus Database: 451 - Release Date: 22/05/2004
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Alex Zinin <[email-masked]>
Date: Thu, 17 Jun 2004 13:12:41 -0700

Kireeti,

  Why isn't the current scheme good enough?

-- 
Alex
http://www.psg.com/~zinin

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 17 Jun 2004 19:03:14 -0700 (PDT)

> which would indicate that the next four bytes is an SNMP ID.

Well, Juniper (and many others, I suspect) doesn't have an OUI.  We do
have an SNMP enterprise code, and if we didn't, it would cost a couple
of emails to get one.  (Alex, does that answer your question?)

[I'm speaking with 20/20 hindsight -- if you look at the RSVP change
draft (draft-kompella-rsvp-change-02.txt), the experimental code space
for uses SNMP enterprise IDs, but the first idea was to use an OUI.]

> I suppose that we could write a new draft that goes
<snipped>

I'd be in violent agreement with this.

> would do that, would they ?

Nah!

> It would give us 64 ways of defining indicators in the future.

Sounds plenty to me.

A poll of how many have implemented the 250 TLV as currently defined
may help sort out how to proceed ....

Juniper hasn't (would you have guessed???)

Kireeti.
-------

---

From: Christian Hopps <[email-masked]>
Date: Fri, 25 Jun 2004 08:38:01 -0700

> Juniper hasn't (would you have guessed???)

Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) 
and skip the compatibility octet, if at all possible.

Rather than have everyone announce who hasn't implemented this draft, I 
would prefer that anyone who has and is against changing the TLV speak 
up. We can take a poll in San Diego as well. If no-one speaks up we 
should change the draft, put it in LC and get it published.

Chris.

---

From: "Philip Christian" <[email-masked]>
Date: Sat, 26 Jun 2004 15:29:20 +0100 (BST)

what is the problem with 1 byte extra ?

i wish that i had put it in from the start

it makes us totally future proof

it is no problem for an implementor because the software will be looking
for a specific pattern of bytes, anything else it just ignores

the pattern is just one byte longer now

Philip

---

From: Christian Hopps <[email-masked]>
Date: Sat, 26 Jun 2004 08:28:13 -0700

> it makes us totally future proof

TLV code points handle this level of future proofing just fine.

> the pattern is just one byte longer now

It's not about TLV space, it's about the design. I (and others who 
should feel free to speak up) don't see any reason to have multiple 
types of differentiators. The problem being solved is simple why not 
keep the solution simple as well?

Chris.

---

From: Jeff Learman <[email-masked]>
Date: Sat, 26 Jun 2004 11:38:47 -0400

I agree that there should be a byte code to identify the kind
of number that follows.  Whether it needs to be backwards compatible
with OUIs is another matter and I have no strong opinion about
that.

Note that I don't speak for Cisco here, just my $0.02.

Jeff

---

From: Jeff Learman <[email-masked]>
Date: Sat, 26 Jun 2004 11:40:59 -0400

>TLV code points handle this level of future proofing just fine.

If that's the case, then we should assign another TLV code for
SNMP IDs.

Jeff

>It's not about TLV space, it's about the design. I (and others who should feel free to speak up) don't see any reason to have multiple types of differentiators. The problem being solved is simple why not keep the solution simple as well?
>
>Chris.
>
>>Philip
>>
>>

---

From: Christian Hopps <[email-masked]>
Date: Sat, 26 Jun 2004 08:48:50 -0700

> with OUIs is another matter and I have no strong opinion about

Why?

Chris.

---

From: "Philip Christian" <[email-masked]>
Date: Sat, 26 Jun 2004 19:48:32 +0100 (BST)

Under my proposal an implementor can put
193+OUI
or
194+SNMP EC

that is a simple solution

I don't understand why anyone would object

I don't think that there is any lack of simplicity

I am including Mike because he was the one originally who asked for OUIs.
If Mike want OUIs and Juniper want SNMP ECs then it seems to me the
simplest way to please both.

Regards, Philip

---

From: Alex Zinin <[email-masked]>
Date: Mon, 28 Jun 2004 16:01:54 -0700

Philip, guys-

 Could someone please explain the _technical_ reason for two numbering schemes,
 while only one is both required and sufficient for interoperability?

---

From: Philip Christian <[email-masked]>
Date: Tue, 29 Jun 2004 11:32:51 +0100

There isn't one.

It pragmatic / procedural decision.

I don't know enough about SNMP IDs to know how easy they are to get, how 
much they cost, if they will ever run out, and if they will always be four 
bytes.  I guess four bytes is a lot of numbers....

The next question is whether anyone has used the OUI scheme, and therefore 
whether there can be an interop problem if an SNMP ID could be used in the 
future the first three bytes of which look like an OUI.

If no-one has implemented then I guess that there is no problem there.  If 
someone has implemented then we would have to put a byte in front of the 
SNMP ID anyway to avoid confusion.

Maybe if someone has implemented the OUI scheme, or is about to then they 
could let me know in confidence and then at least I could state that 
someone has done it without saying who.

Personally I don't really care what the solution is.  I suggested the extra 
byte and allow both because I thought that it would be acceptable to both 
parties.

There seems no technical reason NOT to allow both either, so why not?  I 
can't see what harm it would do.  And who knows what vendor identication 
scheme might become fashionable in the future?  An extra byte will make 
life very easy to cope with it.  Extensibility is a good thing, isn't it?

maybe that is a technical argument after all....

Regards, Philip

At 16:01 28/06/2004 -0700, Alex Zinin wrote:

>Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004

---
Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004