Subject: SCSP MIB: Splitting protocol dependent MIB into two parts

From: [email-masked]
Date: Wed, 17 Dec 1997 09:44:54 -0500

> For example, you want to synchronize ATMARP, NHRP, and M
> using, say, ATM, Ethernet and Frame Relay as the transpo
> for SCSP.                                               
                                                         
> If (b) and (c) were combined into one protocol dependent
> would need 9 protocol dependent MIBs:                   
> |Synchronizing ATMARP with SCSP over ATM                
> |Synchronizing NHRP with SCSP over ATM                  
> |Synchronizing MARS with SCSP over ATM                  
> |Synchronizing ATMARP with SCSP over Ethernet           
> |Synchronizing NHRP with SCSP over Ethernet             
> |Synchronizing MARS with SCSP over Ethernet             
> |Synchronizing ATMARP with SCSP over Frame Relay        
> |Synchronizing NHRP with SCSP over Frame Relay          
> |Synchronizing MARS with SCSP over Frame Relay          

> whereas, if they were separate, you would only need 6 MIBs:    
> |Synchronizing ATMARP     
> |Synchronizing NHRP       
> |Synchronizing MARS       
> |SCSP over ATM            
> |SCSP over Ethernet       
> |SCSP over Frame Relay    
                           
I think SCSP is used for non-broadcast media except the case of DHCP.
ATMARP and MARS are designed specifically over ATM. I can't imagine
the scenarioes you listed above that ATMARP or MARS is run over Ethernet.
For NHRP, it is mostly for ATM for the shortcut. I don't think NHRP will
ever run over ethernet as it makes no sense. Anyway, I don't think
there is a need to separate Link layer into a separate MIB. The protocol
dependent MIB will have the same 3 tables as the protocol independent MIB,
and these tables contain protocol specific information such as the
NBMA address. There is a close association between the protocol dependent
and independent tables, as the entry creation/deletion are tied for the
tables.

---

From: Hoylen Sue <[email-masked]>
Date: Thu, 18 Dec 1997 10:16:12 +1000 (EST)

Cliff,

[email-masked] writes:
 > > using, say, ATM, Ethernet and Frame Relay as the transport
 > > for SCSP.                                               
 >                            
 ...
 > I can't imagine

These were just examples, perhaps I should have used abstract protocols
X, Y and Z.  My thinking is that SCSP is a very generic mechanism, and
might have many uses in the future that we do not know of yet. (e.g. you
could conceivably use it to synchronize address books using UDP) Keeping
the two protocol-dependent protocols separate is more flexible, since
they are conceptually distinct.  But yes, with the current set of
protocol-dependent protocols this flexibility is unnecessary.

Hoylen
__________________________________________________________ Dr Hoylen Sue
[email-masked]                                        +61 7 3259 2222
CiTR Pty Ltd, PO Box 1643, Milton, 4064, Australia. Fax: +61 7 3259 2259
http://www.citr.com.au           http://www.dstc.edu.au/RDU/staff/hoylen

---

From: Hoylen Sue <[email-masked]>
Date: Thu, 18 Dec 1997 10:28:36 +1000 (EST)

Cliff,

[email-masked] writes:
 > Anyway, I don't think
 > NBMA address.

I'm don't think this would work very well. Consider the situation when a
point-to-multipoint connection is used.  The SCSP specification clearly
says:

	An LS must be configured with a list of NBMA addresses which
	represent the peer servers in a SG to which the LS wishes to
	have a direct connection for th epurpose of running SCSP; that
	is, these addresses are the addresses of would-be DCSs.

So, the manager would want to be configuring NBMA address objects rather
than configuring DCS objects.  Again, it comes back to the fact that DCS
objects are automatically discovered by the Hello messages and are not
`persistent' as NBMA addresses.

For example, if the point-to-multipoint address X is associated with
DCSes A, B, C, ... I, J.  Then the manager really just wants to
configure one object X, rather than creating ten DCS objects and then
configuring all ten objects with the same X address.  Unless there is a
table based on NBMA address objects, you're stuck with using the DCS
table --- which is at the wrong granularity for this type of configuration.

If the DCS table is where the NBMA addresses are configured, you will
also need to account for multiple redundent links to the same DCS.  That
is allow for more than one NBMA address for each DCS.

.> There is a close association between the protocol dependent
 > and independent tables, as the entry creation/deletion are tied for the

How is entry creation/deletion tied to the current three tables?  I
thought entries are at a totaly different level altogether, requiring an
additional table to the ones already defined.

Hoylen

P.S. We need a better term than just "NBMA", because the SCSP
specification clearly says that SCSP also works with "BMA" too.
Perhaps something like "transport address" or "SCSP link address".
__________________________________________________________ Dr Hoylen Sue
[email-masked]                                        +61 7 3259 2222
CiTR Pty Ltd, PO Box 1643, Milton, 4064, Australia. Fax: +61 7 3259 2259
http://www.citr.com.au           http://www.dstc.edu.au/RDU/staff/hoylen