Subject: [Hubmib] RE: available connections thoughts

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Mar 2004 17:16:41 +0200

As this work is a hubmib WG item, I would remind everybody who wants to contribute to this discussion to subscribe to [email-masked], in order to enjoy all the replies and discussions. 

Regards,

Dan

> -----Original Message-----
> From: Bob Ray [mailto:[email-masked]]
> Sent: 15 March, 2004 5:14 PM
> To: Menachem Dodge
> Cc: [email-masked]; adslmib mail list; Romascanu, Dan 
> (Dan); [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]>
> 
> 
> 

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Mar 2004 17:16:41 +0200

Regards,

Dan

---

From: [email-masked]
Date: Mon, 15 Mar 2004 18:14:48 +0100

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, 

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

---

From: [email-masked]
Date: Mon, 15 Mar 2004 18:14:48 +0100

Bob,

	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];

Thoughts?

-- 
Bob Ray <[email-masked]>

---

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

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

> 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,
> 
> and group

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 16 Mar 2004 00:21:34 +0100

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

Thanks,
Bert 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: maandag 15 maart 2004 23:36
> To: [email-masked]
> Cc: Menachem Dodge; [email-masked]; [email-masked]; 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
> 
> 
> 
> > Sent: 16 March, 2004 12:23 AM
> > To: Romascanu, Dan (Dan)
> > Cc: Menachem Dodge; [email-masked]; [email-masked]; Mike Sneed
> > 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
> > > 
> > > 
> > >

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 16 Mar 2004 00:21:34 +0100

Thanks,
Bert

---

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

---

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

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-hubmib-efm-mib-00.txt.

Thanks and Regards,

Dan

-----Original Message-----
From: Bob Ray [mailto:[email-masked]]
Sent: 16 March, 2004 3:32 PM
To: Romascanu, Dan (Dan)
Cc: Menachem Dodge; [email-masked]; [email-masked]; Mike Sneed
Subject: Re: [Hubmib] RE: available connections thoughts

On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote:
> 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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Mar 2004 16:16:57 +0200

if-mibers,

Thanks and Regards,

Dan

-----Original Message-----
From: Bob Ray [mailto:[email-masked]]
Sent: 16 March, 2004 3:32 PM
To: Romascanu, Dan (Dan)
Cc: Menachem Dodge; [email-masked]; [email-masked]; Mike Sneed
Subject: Re: [Hubmib] RE: available connections thoughts

-- 
Bob Ray <[email-masked]>

---

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

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

Regards,

Dan

> From: Romascanu, Dan (Dan) 
> Sent: 16 March, 2004 4:17 PM
> To: [email-masked]'
> Cc: [email-masked]'
> 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
> 
> 
>

---

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

Regards,

Dan