Subject: RE: PW MIB suggestion...

From: David Zelig <[email-masked]>
Date: Mon, 15 Apr 2002 10:31:58 +0200

Matt,
Sorry for the delay in answering it, I was out of the office for a long
period. See inline,

David

> -----Original Message-----
> From: Matt Squire [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 5:46 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: PW MIB suggestion...
> 
> 
> 
> After working through the the maze of MIBs a little bit, and listening
> to the all of the calls for better layering principals and 
> architecture
> within PWE3, I wanted to make a suggestion on the PW MIB, or MIB
> architecture in general.  
> 
> Right now, the MIB heirarchy looks like this:
> 
>                      |----------|
>                      |  PW-MIB  |
>                      |----------|
>                        |   |   |
>                        |   |   |
>                 |-------   |   --------|
>                 |          |           | 
>            |---------| |--------| |---------|
>            |MPLS PSN | |  GRE   | |   L2TP  | ...other tunnel types
>            |---------| |--------| |---------|
> 
> I suggest we abstract a generic tunnel layer to contain the common and
> fundamental properties of a tunnel.  The heirarchy would then 
> look like:
>              
>                      |----------|
>                      |  PW-MIB  |
>                      |----------|
>                            |
>                      |----------|
>                      |Tunnel MIB|
>                      |----------|
>                        |   |   |
>                        |   |   |
>                 |-------   |   --------|
>                 |          |           | 
>            |---------| |--------| |---------|
>            |  MPLS   | |  GRE   | |   L2TP  | ...other tunnel types
>            |---------| |--------| |---------|        
> 
> There are mutliple reasons for the change.  
> 
> 1) Simplicity.  There are many things about tunnels that are 
> independent
> of tunnel type:  oper status, admin status, endpoints, tunnel groups,
> mapping PW FECs to tunnels, etc.  Separating out the generic
> characteristics of a tunnel will give us more consistent 
> management and
> control, rather than completely independent MIBs for each.
> 

In designing the MIB structure we should take into account the layering
approach from one hand and the implementation simplicity from the other
hand. The PW MIBs are relatively complex by now (service - pw - psn ). Most
of the items mentioned like AdminStatus, OperStatus etc. are already covered
in the specific PSN MIBs and having them duplicated will require much
complex implementation for coordination, etc. Where they do not exists ,
they are generally either without meaning (what is the meaning of
AdminStatus of IP tunnel?), and either will be added to the PW-PSN specific
MIB.

> 2) Tunnel groups for other tunnel types.  Right now, the MPLS 
> MIB has a
> very flexible grouping strategy, where tunnels can back each 
> other up or
> loadshare across a network.  It would be nice to extend this 
> capability
> to other tunnel types.  In a non-connection oriented IP network its
> certainly fair to question the utility of having one GRE 
> tunnel back up
> another (for example), but such backup IP tunnels can be useful in the
> case of interface failures on a remote device (ie the IP address you
> connected to fails but others interfaces on that box remain
> operational).  
> 
We considered in the past having multiple indexes to the VC table but we
found it complex to implement (and describe...). See further the answer for
3) below.

> 3) Mixed tunnel groups.  We have found it very useful to be able to
> backup an MPLS tunnel(s) with an IP tunnel (GRE or L2TP).  The
> reliability and resiliency of MPLS networks is still in the improving
> stage, and having the capability to switch to IP tunnels in 
> the event of
> MPLS failures is very useful failsafe.  
> 
This issue was raised in the past on the mailing list, but since there are
yet no documents that describe such operation, we should be careful not to
specify the behavior through the MIB. Some question for example: do you use
the same VC label for the backup IP tunnel? does it have a separate
signaling session?. Different answers will imply different MIB structure so
in this case I prefer to see first an agreed i-d. In any case, in my opinion
it can be done based on the current indexing.

> So my suggestion would be to develop a common tunnel table to hold the
> basic characteristics of a tunnel that are independent of the 
> particular
> tunneling technology, and move technology specific tunnel
> characteristics to their separate MIBs.  
> 
> - Matt
>