Subject: Re: RFC2514 v1.1

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 12 Oct 1999 18:17:03 -0400

Kaj,

My $.02 (disclosure: this is wearing my FRNETMIB chair hat) is let's get 
the 2514 update out as an RFC ASAP.  If we want to get anything else 
included at the same time, let's do it as expeditiously as possible, by 
which I mean speak Real Soon Now on this list (and propose specific text) 
or forever hold your peace.  I would propose a specific time limit for new 
text proposals, such as by the IETF meeting.  That way we can hold some 
hallway conversations if necessary in Washington, and the revised 2514 can 
get out as a draft as soon as the I-D blackout lifts.

Cheers,
Andy

--------

At 12:01 PM 10/11/1999 -0400, Kaj Tesink wrote:
>hi all, a quick status update on this.
>
>a) the frame relay wg has requested an additional
>    enumerated value in AtmConnKind in order to accommodate
>    the FR/ATM interworking case. in addition, a proprietary
>    interworking case should be recognized.
>
>    because of document interdependencies RFC2514 needs to
>    be revised quickly to make everything work.
>
>    there has been discussion on how to accommodate this change
>    and it seems workable.
>    the change proposed by Ken Rehbehn is attached (i may use a REFERENCE 
> clause
>    instead of the [ref])
>
>b) if we change 2514 anyway then we just as well accommodate any
>    other nits that may be outstanding.
>    one thing that Gary Hanson flagged is to add the GFR traffic type
>    (proposed text invited).
>
>please holler if you have any comments on these proposed changes
>or if there are any other minor issues that should be accommodated
>while we're on it.
>
>kaj
>
>
>
>
>
>
>>From: "Rehbehn, Kenneth" <[email-masked]>
>>To: "'Kaj Tesink'" <[email-masked]>
>>Subject: FR/ATM IWF Support Change for ATM MIB TC
>>Date: Tue, 5 Oct 1999 14:55:57 -0400
>>Importance: high
>>X-Mailer: Internet Mail Service (5.5.2448.0)
>>
>>Kaj:
>>
>>Thank you for your help in this process.  Could you please start the process
>>to update RFC 2514 with the additional codepoints needed to support FR/ATM
>>PVC Service IWF?
>>
>>To help move things faster I have provided a redefined AtmConnKind in the
>>attached file.
>>
>>Please advise when you think a new RFC will be published.  In addition to
>>RFC 2514v2, the FR/ATM PVC Service IWF MIB needs to undergo IESG review
>>before that MIB or the Frame Relay Service MIB can be published as RFCs.
>>
>>Cheers,
>>Ken
>>
>>---------------------------------------------------------------
>>Ken Rehbehn                              Phone: +1-301-296-2325
>>Visual Networks                            Fax: +1-301-296-2302
>>2092 Gaither Rd              EMail: [email-masked]
>>Rockville, MD  20850              http://www.visualnetworks.com
>>
>
>--------------------------------------------------------------------------- 
>----
>
>
>                        Modification to RFC 2514
>
>The following changes are required in RFC 2514, "Definitions of
>Textual Conventions and OBJECT-IDENTITIES for ATM Management".
>
>The support for cross-connection to ATM interworking functions
>enables co-existance with the FR/ATM Service IWF.  A proprietary
>enumerated value is included to cover implementation-specific
>cross-connect tables.  An enumeration may be required in the future
>to support a CES IWF.  However, no CES endpoint MIB exists today and
>so this case has not been included.
>
>
>1)  Modify the following TEXTUAL-CONVENTION:
>
>     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.
>                    atm2frServiceIWF(6)
>                       Virtual link at the ATM side of a
>                       FR/ATM Service IWF crossconnect,
>                       where the IWF is the target of the
>                       ATM PVC segment.  The
>                       frAtmIwfConnectionTable crossconnect
>                       table described in [4] connects the
>                       frame relay to ATM segments.
>                    atm2proprietaryIWF(7)
>                       Virtual link at the ATM side of a
>                       ATM to proprietary IWF, where the
>                       IWF is the target of the ATM PVC
>                       segment.  The crossconnect table is
>                       implementation-specific and beyond
>                       the scope of this MIB.
>
>                 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),
>            atm2frServiceIWF(6),
>            atm2proprietaryIWF(7)
>            }
>
>
>2) Add the following reference:
>
>    [4]  Rehbehn, K., Nicklass, O., and G. Mouradian, "Definitions of
>         Managed Objects for Monitoring and Controlling the Frame
>         Relay/ATM PVC Service Interworking Function, RFC xxxFRATMMIBxxx,
>         October 1999
>
>
>
>
>
>
>
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>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
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414  fax:978 392-2074
Lucent Technologies                 1 Robbins Road    Westford, MA 01886

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 19 Oct 1999 11:32:35 -0400

>get out as a draft as soon as the I-D blackout lifts.

hi andy,
i agree with your philosophy - just posted draft text for the GFR traffic 
types.
as you can imagine my selfish interest includes minimizing the number of times
we should confuse everyone with rfc revisions :-)

kaj

>>-------------------------------------------------------------------------- 
>>- ----
>>
>>
>>                        Modification to RFC 2514
>>

Kaj Tesink