headers
jcucchiara | 3 Aug 2004 20:41
Picon

question on the isisSysProtSuppTable in draft-ietf-isis-wg-mib-16.txt


Hi Jeff,

I have two question regarding the isisSysProtSuppTable:

1)  Why can't this table be reduced to a  scalar, read-only object with type BITS which 
can be queried by an operator to see what the router supports?

2) How is the operator going to know what protocols the router supports, because
   there doesn't exist any object which tells the operator?

The current table assumes that the operator "knows" what protocols are supported and
I don't see anything in the MIB that tells the operator this info.

   thanks, 
     -Joan
Permalink | Reply | 0 comments |
headers
Jeff Parker | 3 Aug 2004 21:47

RE: question on the isisSysProtSuppTable in draft-ietf-isis-wg-mi b-16.txt


> Hi Jeff,
> 
> I have two question regarding the isisSysProtSuppTable:
> 
> 1)  Why can't this table be reduced to a  scalar, read-only 
> object with type BITS which 
> can be queried by an operator to see what the router supports?

Yup, that could be done
> 
> 2) How is the operator going to know what protocols the 
> router supports, because
>    there doesn't exist any object which tells the operator?

I assume that the operator will do a get-next walk over the table, and
retrieve the rows.  Each row represents a different supported protocol

    IsisSysProtSuppEntry ::=
        SEQUENCE {
            isisSysProtSuppProtocol
                IsisSupportedProtocol,
            isisSysProtSuppExistState
                RowStatus
            }

> The current table assumes that the operator "knows" what 
> protocols are supported and
> I don't see anything in the MIB that tells the operator this info.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Don Goodspeed | 3 Aug 2004 23:43
Picon

RE: RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt

Jeff, Joan,

If we are truly having this be a read-only table, then
it can just be a scalar object with BITS as the definition,
and each bit representing each protocol:

    isisSysProtSupported OBJECT-TYPE
        SYNTAX BITS {
                    iso8473 (0),
                    ipv4 (1),
                    ipv6 (2)
                  }
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "This attribute contains the set of protocols
             supported by this Intermediate System."
    ::= { isisSysObject 12 }

One could then get rid of the existing table and the TC
SupportedProtocol.

-don

-----Original Message-----
From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org]On
Behalf Of Jeff Parker
Sent: Tuesday, August 03, 2004 12:47 PM
To: 'jcucchiara <at> mindspring.com'
Cc: isis-wg <at> ietf.org; James Halpin
(Continue reading)

Permalink | Reply | 1 comment |
headers
jcucchiara | 4 Aug 2004 03:20
Picon

RE: RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt


Hi Don,

At 02:43 PM 8/3/04 -0700, Don Goodspeed wrote:
>Jeff, Joan,
>
>If we are truly having this be a read-only table, then
>it can just be a scalar object with BITS as the definition,
>and each bit representing each protocol:
>
>    isisSysProtSupported OBJECT-TYPE
>        SYNTAX BITS {
>                    iso8473 (0),
>                    ipv4 (1),
>                    ipv6 (2)
>                  }
>        MAX-ACCESS read-only
>        STATUS current
>        DESCRIPTION
>            "This attribute contains the set of protocols
>             supported by this Intermediate System."
>    ::= { isisSysObject 12 }

Awesome!

>
>One could then get rid of the existing table and the TC
>SupportedProtocol.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Harrison | 4 Aug 2004 16:00
Favicon

RE: RE: question on the isisSysProtSuppTable indraft-ie tf-isis-wg-mib-16.txt

Don, Jeff, Joan,

I agree that a single scalar BITS object is simpler than the current
isisSysProtSupp table.  However, I think that operators may want to
configure the set of protocols (for example, to enable or disable IS-IS for
IPv6), and so the object should have read-write access.

Jon

-----Original Message-----
From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org]On
Behalf Of Don Goodspeed
Sent: 03 August 2004 22:43
To: 'Jeff Parker'; jcucchiara <at> mindspring.com
Cc: isis-wg <at> ietf.org; 'James Halpin'
Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable
indraft-ietf-isis-wg-mi b-16.txt

Jeff, Joan,

If we are truly having this be a read-only table, then
it can just be a scalar object with BITS as the definition,
and each bit representing each protocol:

    isisSysProtSupported OBJECT-TYPE
        SYNTAX BITS {
                    iso8473 (0),
                    ipv4 (1),
                    ipv6 (2)
                  }
(Continue reading)

Permalink | Reply | 0 comments |
headers
jcucchiara | 4 Aug 2004 16:11
Picon

RE: RE: question on the isisSysProtSuppTable indraft-ie tf-isis-wg-mib-16.txt


Jon,

Perhaps 2 scalars are needed.

One which is read-only which Don outlined, because the operator is going
to need to know what protocols are supported by the router.  Even though
the MIB object specifies the possibility 3 different protocols, it might be that
a router vendor does NOT support all 3 of these to begin with.  It would be
very clear to an operator what is or is not supported with this read-only object.
This would be new to the MIB.

The  other object  is read-write would be for the reasons you state below, and would
replace the isisSysProtTable.

I would be in favor of removing the isisSysProtSuppTable and replacing this
with 2 scalars. 

   thanks, 
     - Joan

-----Original Message-----
From: Jonathan Harrison <jon.harrison <at> dataconnection.com>
Sent: Aug 4, 2004 10:00 AM
To: "'Don.Goodspeed <at> alcatel.com'" <Don.Goodspeed <at> alcatel.com>, 
	'Jeff Parker' <jparker <at> axiowave.com>, jcucchiara <at> mindspring.com
Cc: isis-wg <at> ietf.org
Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ie	tf-isis-wg-mib-16.txt

Don, Jeff, Joan,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alex Zinin | 5 Aug 2004 01:51

Comments on draft-shen-isis-extended-tlv-00.txt

A few comments I raised at the mic today:

1. One of the reasons that was mention was exhaustion of the TLV type
   space. Given that we have only 36 allocations in the registry now,
   I doubt this will be a problem any time soon.

2. Another reason was the size of the TLV. If this becomes a problem,
   my first question would be whether this is a good idea to announce
   such info in ISIS and/or whether it is properly encoded. This is not
   to say that we could never end up with having to announce something
   bigger than 255, but I'd like to see an example of where this becomes
   a problem we can't get around.

3. Naming mentioned in his slides that backwards-compatible deployment
   is possible. I wasn't sure it was. Now that I re-read the draft, I'm
   sure it is not possible. Routers not implementing this feature will
   encounter a TLV parsing error, since the what they believe is the 1-octet
   length field will contain wrong value for TLVs bigger than 255 octets.

--

-- 
Alex
http://www.psg.com/~zinin
Permalink | Reply | 1 comment |
headers
mike shand | 5 Aug 2004 02:59
Picon
Favicon

Re: Comments on draft-shen-isis-extended-tlv-00.txt

At 16:51 04/08/2004 -0700, Alex Zinin wrote:
>A few comments I raised at the mic today:
>
>1. One of the reasons that was mention was exhaustion of the TLV type
>    space. Given that we have only 36 allocations in the registry now,
>    I doubt this will be a problem any time soon.

I agree. And not only that, we have sub-TLVs for things that need a lot of 
code points.

>2. Another reason was the size of the TLV. If this becomes a problem,
>    my first question would be whether this is a good idea to announce
>    such info in ISIS and/or whether it is properly encoded. This is not
>    to say that we could never end up with having to announce something
>    bigger than 255, but I'd like to see an example of where this becomes
>    a problem we can't get around.

I agree. This seems to be a somewhat Draconian solution to a problem which 
we don't know we have yet, and which IF we do have may well be solvable by 
simpler techniques (such as defining the contents of TLVs to be additive, 
in the same way that we can have more prefixes than will fit in a single 
TLV by repeating the TLV and "adding" the prefixes together; I agree it is 
not quite as simple as that in some case, but that seems to me to be a less 
disruptive way of addressing the problem should it ever arise; and I 
sincerely hope it doesn't:-)

>3. Naming mentioned in his slides that backwards-compatible deployment
>    is possible. I wasn't sure it was. Now that I re-read the draft, I'm
>    sure it is not possible. Routers not implementing this feature will
>    encounter a TLV parsing error, since the what they believe is the 1-octet
(Continue reading)

Permalink | Reply | 0 comments |
headers
Naiming Shen | 6 Aug 2004 01:35

Re: Comments on draft-shen-isis-extended-tlv-00.txt


Alex,

 ] A few comments I raised at the mic today:
 ] 
 ] 1. One of the reasons that was mention was exhaustion of the TLV type
 ]    space. Given that we have only 36 allocations in the registry now,
 ]    I doubt this will be a problem any time soon.

Agreed. But this code point is a side effect of the draft. I think anyone
would agree that if we take the trouble to change the length field,
the code field better to be changed at the same time.

 ] 
 ] 2. Another reason was the size of the TLV. If this becomes a problem,
 ]    my first question would be whether this is a good idea to announce
 ]    such info in ISIS and/or whether it is properly encoded. This is not
 ]    to say that we could never end up with having to announce something
 ]    bigger than 255, but I'd like to see an example of where this becomes
 ]    a problem we can't get around.

Ok, let me list some of the reasoning here, others can contribute too,

 - network transition is not easy, it can takes years to finish, for
   all the boxes converge into the same capabilities.

 - a pure historical note: at the time we desgined the Multi-Topology
   IS-IS, there was a choice to use the existing TLV 22 and 135. But the
   major concern at the time was if there were multiple topologies using
   TE (not even talking about GMPLS), then the 255 bytes of the TLV would
(Continue reading)

Permalink | Reply | 0 comments |
headers
Suresh Boddapati | 6 Aug 2004 20:06
Picon
Favicon

Re: Comments on draft-shen-isis-extended-tlv-00.txt

I think there are two questions to be answered here.

1) Is there an application where the data is large enough that it will not 
fit within one TLV? Note here we are talking about something that cannot be 
fit into a TLV using "additive" style like Mike mentioned. I believe Dimitri 
said that they had to get around the GMPLS problem by defining additional 
TLVs. I dont believe Dimitri said there is a problem currently. Dimitri, can 
you please elaborate on this? What is the diffserv data that you consider 
will require more than 255 bytes and cannot be intelligently broken down 
into multiple TLVs?

2) Suppose we assume that we have data that is large enough that it wont fit 
into one TLV which means the data is larger than 255 bytes. Why are we 
trying to solve it using a low byte and a high byte? Are you assuming that 
the data will not be larger than the most often used 1492 bytes of an ISIS 
LSP? The order of difference between 255 and 1492 (to be more precise 1469, 
after taking out 20 bytes of LSP header + 3 bytes for Type, low byte and 
high byte) is not too much. What if tomorrow there is a need to send 1500 
bytes of data or more in an LSP because of some application. Your scheme 
will not work. If we are to conclude that there is a problem with sending 
large data in ISIS, then why dont we fix it once and for all by fragmenting 
the data and using fragment IDs for each chunk of the data in a new TLV, 
which then can be repeated as many times as desired. Then we dont even have 
to worry about backwards compatibility which your draft tries to deal with. 
We dont have to have these three modes; if an implementation does not 
support this new TLV, it will simply ignore it (and all occurrences of it). 
I would be happy to write this up. Heck, then we can even send MP3 files 
through ISIS :-)

All said and done, it seems that we may be trying to solve a problem that
(Continue reading)

Permalink | Reply | 3 comments |

Gmane