Subject: [Hubmib] RE: available connections thoughts

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Mar 2004 00:36:11 +0200

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:[email-masked]]
> Sent: 16 March, 2004 12:23 AM
> To: Romascanu, Dan (Dan)
> Cc: Menachem Dodge; [email-masked]; [email-masked]; 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.  
> 
> 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
>    }
> 
> availabilityStatus OBJECT-TYPE
>    SYNTAX Integer32
>           {
>              available(1),  -- can be connected
>              inUse(2),      -- exclusively connected
>              blocked(3)     -- administratively blocked
>           }
> 
> Does that make sense?  Please excuse any syntactical errors,
> I'm just trying to communicate an idea :)
> 
> Regards,
> Bob Ray
> 
> On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote:
> > 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: [email-masked] 
> [mailto:[email-masked]]
> > > Sent: 15 March, 2004 7:15 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]; Romascanu, Dan (Dan); 
> > > [email-masked]; [email-masked]
> > > 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:[email-masked]] 
> > > Sent: Monday, March 15, 2004 5:14 PM
> > > To: Menachem Dodge
> > > Cc: [email-masked]; adslmib mail list; [email-masked];
> > > [email-masked]; 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
> > >     to Y.  The most obvious example (for me) is where a 
> > >     broadcast facility might not want adult video sources 
> > >     to EVER be connected to a religious video feed.
> > > 
> > > Less obvious examples can be constructed (i.e. data 
> > > security). Does this
> > > make sense?
> > > 
> > > Building upon this, one might have interface group constructs 
> > > and group
> > > level blocking - group A can connect to group B, but group A 
> > > cannot connect
> > > to anything from group C.
> > > 
> > > Thoughts?
> > > 
> > > -- 
> > > Bob Ray <[email-masked]>
> > > 
> > > 
> -- 
> Bob Ray <[email-masked]>
> 
> 
> 

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: Bob Ray <[email-masked]>
Date: Tue, 16 Mar 2004 07:32:29 -0600

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.

> physically be connected, which seems kinda pointless.  

In which I meant, "I see no sense to a nonexistant enumeration".  
Which is why I left it out of the later enumeration. :)

-- 
Bob Ray <[email-masked]>

---

From: Bob Ray <[email-masked]>
Date: Tue, 16 Mar 2004 07:32:29 -0600

-- 
Bob Ray <[email-masked]>