headers
Romascanu, Dan (Dan | 16 Mar 2004 15:17
Favicon

RE: RE: available connections thoughts

Sorry, the correct reference is http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt

Regards,

Dan

> -----Original Message-----
> From: Romascanu, Dan (Dan) 
> Sent: 16 March, 2004 4:17 PM
> To: 'ifmib <at> ietf.org'
> Cc: 'hubmib <at> ietf.org'
> Subject: FW: [Hubmib] RE: available connections thoughts
> 
> 
> if-mibers,
> 
> This discussion happening in the hubmib wg may benefit from 
> your feedback. The I-D in cause is 
> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-h
> ubmib-efm-mib-00.txt.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> -----Original Message-----
> From: Bob Ray [mailto:rray <at> pesa.com]
> Sent: 16 March, 2004 3:32 PM
(Continue reading)

Permalink | Reply |
headers
Wijnen, Bert (Bert | 16 Mar 2004 00:21
Picon
Favicon

RE: RE: available connections thoughts

I wonder if this discussion does not belong on ifmib mailing list?

Thanks,
Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
> Sent: maandag 15 maart 2004 23:36
> To: rray <at> pesa.com
> Cc: Menachem Dodge; EdwardB <at> actelis.com; hubmib <at> ietf.org; Mike Sneed
> Subject: [Hubmib] RE: available connections thoughts
> 
> 
> This is better. However, your proposal lights another warning 
> beacon for me. Would not this 'nonexistent' value lead to an 
> un-justified multiplication of the number of rows? We should 
> be careful here. The ifStack like models have little 
> deployment today, and the concern about the multiplication of 
> the number of entries in devices with multiple overlayed 
> interfaces may be related. What is the opertional benefit 
> from having a 'nonexistant' enumerated value defined?
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: Bob Ray [mailto:rray <at> pesa.com]
(Continue reading)

Permalink | Reply |
headers
Romascanu, Dan (Dan | 15 Mar 2004 23:36
Favicon

RE: available connections thoughts

This is better. However, your proposal lights another warning beacon for me. Would not this 'nonexistent'
value lead to an un-justified multiplication of the number of rows? We should be careful here. The ifStack
like models have little deployment today, and the concern about the multiplication of the number of
entries in devices with multiple overlayed interfaces may be related. What is the opertional benefit
from having a 'nonexistant' enumerated value defined?

Thanks and Regards,

Dan

> -----Original Message-----
> From: Bob Ray [mailto:rray <at> pesa.com]
> Sent: 16 March, 2004 12:23 AM
> To: Romascanu, Dan (Dan)
> Cc: Menachem Dodge; EdwardB <at> actelis.com; hubmib <at> ietf.org; Mike Sneed
> Subject: RE: available connections thoughts
> 
> 
> I meant a new textual convention or enumeration, not 
> RowStatus. Similar, I suppose in some ways, but capable 
> of handling adminstrative blocking.
> 
>     availabilityStatus.x.y = blocked
> or  availabilityStatus.x.y = available
> or  availabilityStatus.x.y = inUse
> or  availabilityStatus.x.y = nonexistant 
> 
> Note that "nonexistant" implies that the hypothetical 
> "can connect" table would track that two interfaces cannot
> physically be connected, which seems kinda pointless.
(Continue reading)

Permalink | Reply |
headers
Bob Ray | 16 Mar 2004 14:32

Re: RE: available connections thoughts

On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote:
> This is better. However, your proposal lights another warning
> beacon for me. Would not this 'nonexistent' value lead to an 
> un-justified multiplication of the number of rows? We should be
> careful here. The ifStack like models have little deployment 
> today, and the concern about the multiplication of the number 
> of entries in devices with multiple overlayed interfaces may 
> be related. What is the opertional benefit from having a 
> 'nonexistant' enumerated value defined?

Anything that manages a large number of interfaces (such as 
an OC-3/12 to dsl bridge/router), and that is based to some
degree upon the cross product of the ifTable is gonna be huge. 

The current ifStackTable and ifInvStackTable have entries 
for unconnected upper and lower interfaces.  From RFC2864:

   "For example, two rows exist even for an interface which has
    no others stacked on top or below it:

       ifInvStackStatus.z.0=active
       ifInvStackStatus.0.z=active

    This table contains exactly the same number of rows as the
    ifStackTable, but the rows appear in a different order."

I suspect a "nonexistant" enumeration is equivalent to the above.
You may have noted my comment that:

> Note that "nonexistant" implies that the hypothetical
(Continue reading)

Permalink | Reply |
headers
Romascanu, Dan (Dan | 15 Mar 2004 23:01
Favicon

RE: available connections thoughts

Actually this use of RowStatus in the EFM Cu MIB is not a good design, and may not fly with the MIB Doctors. 

Regards,

Dan

> -----Original Message-----
> From: Menachem.Dodge <at> infineon.com [mailto:Menachem.Dodge <at> infineon.com]
> Sent: 15 March, 2004 7:15 PM
> To: rray <at> pesa.com; Menachem.Dodge <at> infineon.com
> Cc: EdwardB <at> actelis.com; Romascanu, Dan (Dan); 
> hubmib <at> ietf.org; sneedmike <at> hotmail.com
> Subject: RE: available connections thoughts
> 
> 
> Bob,
> 
> 	"Administrative" blocking would certainly be a useful feature to
> have in addition to the
> physical possibility of connection. An additional field would 
> be required in
> the MIB as the RowStatus is read-only
> and shows device capability.
> 
> 	Regards,
> 	Menachem
> 
> -----Original Message-----
> From: Bob Ray [mailto:rray <at> pesa.com] 
> Sent: Monday, March 15, 2004 5:14 PM
(Continue reading)

Permalink | Reply |
headers
Bob Ray | 15 Mar 2004 23:22

RE: available connections thoughts

I meant a new textual convention or enumeration, not 
RowStatus. Similar, I suppose in some ways, but capable 
of handling adminstrative blocking.

    availabilityStatus.x.y = blocked
or  availabilityStatus.x.y = available
or  availabilityStatus.x.y = inUse
or  availabilityStatus.x.y = nonexistant 

Note that "nonexistant" implies that the hypothetical 
"can connect" table would track that two interfaces cannot
physically be connected, which seems kinda pointless.  

In fact, in the prior discussion, there was no real
need for RowStatus other than to have something in the
table.  Either the tuple was there or it wasn't, correct?
That is, it was either "active" or not there.

So, I'm suggesting something on the order of...

canConnectEntry  OBJECT-TYPE
   blah blah
   INDEX { ifIndex, ifIndex }

CanConnectEntry ::=
   SEQUENCE
   {
   availabilityStatus               Integer32
   }
(Continue reading)

Permalink | Reply |
headers
Menachem.Dodge | 15 Mar 2004 18:14

RE: available connections thoughts

Bob,

	"Administrative" blocking would certainly be a useful feature to
have in addition to the
physical possibility of connection. An additional field would be required in
the MIB as the RowStatus is read-only
and shows device capability.

	Regards,
	Menachem

-----Original Message-----
From: Bob Ray [mailto:rray <at> pesa.com] 
Sent: Monday, March 15, 2004 5:14 PM
To: Menachem Dodge
Cc: EdwardB <at> actelis.com; adslmib mail list; dromasca <at> avaya.com;
hubmib <at> ietf.org; Mike Sneed
Subject: available connections thoughts

I think the can-connect tables (Edward's efcCuAvailableStackTable and a
proposed InvAvailableTable) need something more than a RowStatus object.
That is, it would be useful to identify a possible connection as being
**administratively** blocked.  That is, that a connection is physically
possible but blocked for administrative purposes.

Expanding upon the broadcast video example I used in an earlier email, 

    If video input X can be connected to video output Y
    then an entry would exist in the **can connect** table.
(Continue reading)

Permalink | Reply |
headers
Romascanu, Dan (Dan | 15 Mar 2004 16:16
Favicon

RE: available connections thoughts

As this work is a hubmib WG item, I would remind everybody who wants to contribute to this discussion to
subscribe to hubmib <at> ietf.org, in order to enjoy all the replies and discussions. 

Regards,

Dan

> -----Original Message-----
> From: Bob Ray [mailto:rray <at> pesa.com]
> Sent: 15 March, 2004 5:14 PM
> To: Menachem Dodge
> Cc: EdwardB <at> actelis.com; adslmib mail list; Romascanu, Dan 
> (Dan); hubmib <at> ietf.org; Mike Sneed
> Subject: available connections thoughts
> 
> 
> I think the can-connect tables (Edward's efcCuAvailableStackTable
> and a proposed InvAvailableTable) need something more than a
> RowStatus object.  That is, it would be useful to identify a
> possible connection as being **administratively** blocked.  That
> is, that a connection is physically possible but blocked for
> administrative purposes.
> 
> Expanding upon the broadcast video example I used in an earlier
> email, 
> 
>     If video input X can be connected to video output Y
>     then an entry would exist in the **can connect** table.
> 
>     However, there may be reasons to NOT allow X to connect
(Continue reading)

Permalink | Reply |

Gmane