Subject: Re: RFC2514 v1.1

From: Kaj Tesink <[email-masked]>
Date: Wed, 03 Nov 1999 11:37:57 -0400

hi Mike,

i have been thinking about this for a while; my interpretation is
as follows.

historically both the atm and the fr mib have been developed based on
a black box or service model. the implications are as follows:
- internals of a switch are hidden for the outside from a management
   perspective, e.g., cascading of queues is not visible; its only
   the outside behavior (the service) that is visible.
- this model also allowed these mibs to be applied to a network as a whole;
   in that case individual switches would be invisible and only the
   network service as a whole would be visible from a management perspective.

so the idee is that you can apply the mib to the level of detail that
you are interested in. this helped us get around many proprietary issues
(for which enterprise-specific extensions may be used) and it also allowed
the use of these mibs for customer network management.

it seems to me that your proposal would depart from this model in that
you poke more into the internals of a particular switch (iwf) design.
given the stage where we're at and in the absence of further
opinions i suggest that we go ahead with the structure as proposed
by the IWF work.

kaj

At 12:12 PM 10/19/99 -0700, Michael H. Grobelch wrote:
>
>  >From: "Rehbehn, Kenneth" <[email-masked]>
>  >To: "'Michael H. Grobelch'" <[email-masked]>
>  >Cc: [email-masked],
>  >        "Rehbehn, Kenneth"
>  >      <[email-masked]>
>  >Subject: RE: RFC2514 v1.1
>  >Date: Tue, 19 Oct 1999 13:54:44 -0400
>  >
>  >> I believe adding atm2frServiceIWF and atm2proprietaryIWF to
>  >> AtmConnKind is broken.
>  >>
>  >> The purpose/use of a VC is orthogonal to the kind of VC it is.
>  >> It is quite possible to use Soft PVCs, SVCs, or PVCs for frame-relay.
>  >>
>  >
>  >Interconnection with a frame relay endpoint requires a different
>  >cross-connect table than that used by ATM SPVCs or PVCs.  That makes the
>  >FR/ATM IWF a different kind of PVC endpoint and the use of the AtmConnKind
>  >is appropriate to make that distinction.
>
>ATM-ATM and ATM-Frame Relay cross-connects may both
>be needed, and the ATM-Frame Relay cross-connect need not
>distinguish between SVC/PVC/Soft PVC on the ATM side.
>
>Mike

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies (formerly Bellcore)
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 3 Nov 1999 19:01:31 -0800 (PST)

Kaj,
 
> the use of these mibs for customer network management.

I agree with the above.

> opinions i suggest that we go ahead with the structure as proposed
 
I don't know whether or not Mike's objection is dependent on poking
into the internals of a particular switch design.  But, it doesn't
matter, since I have an objection which is based on something
different: on not overloading the definition of an existing object
with new semantics.

Specifically, the fact that draft-ietf-frnetmib-atmiwf-03.txt is only
concerned with PVCs should not be allowed to obscure the architectural
issue here: that whether a connection is a PVC or an SVC is orthogonal
to whether it's ATM-to-ATM or ATM-to-FR.

Specifically, it's worth recalling the definition:

    AtmConnKind ::= TEXTUAL-CONVENTION
            STATUS  current
            DESCRIPTION
                "The type of call control used for an ATM
                connection at a particular interface. The use
                is as follows:
                   pvc(1)
                      Virtual link of a PVC. Should not be
                      used for an PVC/SVC (i.e., Soft PVC)
                      crossconnect.
                   svcIncoming(2)
                      Virtual link established after a
                      received signaling request to setup
                      an SVC.
                   svcOutgoing(3)
                      Virtual link established after a
                      transmitted or forwarded signaling
                      request to setup an SVC.
                   spvcInitiator(4)
                      Virtual link at the PVC side of an
                      SVC/PVC crossconnect, where the
                      switch is the initiator of the Soft PVC
                      setup.
                   spvcTarget(5)
                      Virtual link at the PVC side of an
                      SVC/PVC crossconnect, where the
                      switch is the target of the Soft PVC
                      setup.
 
                For PVCs, a pvc virtual link is always cross-
                connected to a pvc virtual link.
 
                For SVCs, an svcIncoming virtual link is always cross-
                connected to an svcOutgoing virtual link.
 
   For Soft PVCs, an spvcInitiator is either cross-connected to
   an svcOutgoing or an spvcTarget, and an spvcTarget is either
   cross-connected to an svcIncoming or an spvcInitiator."
        SYNTAX   INTEGER {
           pvc(1),
           svcIncoming(2),
           svcOutgoing(3),
           spvcInitiator(4),
           spvcTarget(5)
           }

If you read the first words of that description, they say: "The type of
call control ...".  The difference between ATM-to-ATM or ATM-to-FR
is *not* a type of call control !! 

Thus, the architecturally-new semantic of whether it's ATM-to-ATM or
ATM-to-FR needs to be defined in a new object, not in one based on
the AtmConnKind TC.

Note that this argument does not appear to apply to frPVCEndptConnKind.
Perhaps, the confusion here is that the similarity in the two names
frPVCEndptConnKind and atmVclConnKind is making people think they have
the same semantics, even though they do not.

Keith.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 04 Nov 1999 11:41:57 -0500

Keith,

What AtmConnKind is actually doing is choosing the proper cross-connect 
table to use.  When AtmConnKind is 1, you use atmVcCrossConnectTable in RFC 
2515, when it is 2-5 you use atmSvcVcCrossConnectTable in the atm2 MIB.  So 
AtmConnKind was overloaded, in practice if not by original design.  This 
change would just introduce a new value, and a new cross-connect table to 
use.  If necessary, new values can be introduced in the future for an 
FR/ATM SVC and SPVC cross-connect table.

I would like for us to come to swift closure on this issue, since yesterday 
was the end of the WG last call for the interworking MIB, and this could 
also possibly affect the RFC 1604 replacement, which is now in IETF last call.

If you don't agree with this particular interpretation of AtmConnKind, then 
I would ask for a timely concrete proposal for the new object you discuss 
below.

Thanks,
Andy

-------

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 04 Nov 1999 19:15:07 -0500

At 11:41 AM 11/4/99 -0500, Andrew G. Malis wrote:
>table to use.  When AtmConnKind is 1, you use atmVcCrossConnectTable in 
>RFC 2515, when it is 2-5 you use atmSvcVcCrossConnectTable in the atm2 
>MIB.  So AtmConnKind was overloaded, in practice if not by original 
>design.  This change would just introduce a new value, and a new 
>cross-connect table to use.  If necessary, new values can be introduced in 
>the future for an FR/ATM SVC and SPVC cross-connect table.

i confess that i preferred this solution for exactly that reason - it seems 
a simple extension of
the (perhaps already overloaded) TC. note that an additional object also 
implies that we'll have
to open up the atm mib again which i'd only recommend if other solutions 
are clearly inferior.

>I would like for us to come to swift closure on this issue, since 
>yesterday was the end of the WG last call for the interworking MIB, and 
>this could also possibly affect the RFC 1604 replacement, which is now in 
>IETF last call.

echo

>If you don't agree with this particular interpretation of AtmConnKind, 
>then I would ask for a timely concrete proposal for the new object you 
>discuss below.

echo

cheers,

kaj

Kaj Tesink